Re: Preparing Debian for using capabilities: file ownership.

[Brian May <bam@debian.org>]

>>>>> "s" == s Lichtmaier <Nicol> writes:

    >> > That's not true, capabilities can be handled with system
    >> calls. A daemon > may drop all capabilities except the one
    >> needed to bind to privileged ports.  > But the daemon would
    >> still be ran with UID 0, and be able to modify/access > any
    >> root owned file in the system.
    >> 
    >> Why wouldn't it also change its uid to that of daemon or nobody
    >> then? I assume capabilities are independent of uid?

    s>  If you change RUID, EUID and SUID to a non-root user, all
    s> capabilities are cleared.  Besides, this is the way it will be
    s> done when cap. enabled filesystems arrive.

Can somebody please clarify this statement for a brain-less idiot like
me ;-). What do you mean "all capabilities are cleared"? Is this for
the current process?

Also, quickly glancing through this thread raises the following issues,
which I can't see answers to:

- is root still required? If so why and what for?

- if files are owned by bin:bin, does this mean root no longer
can change them (assuming everything is set up correctly)?

- what is the current status of capabilities in Linux? Last I heard,
it was so limited that it was next to useless. I hope this has/will
change.

- is it practical/possible to initially support both systems, but have
capabilities as an option that is disabled by default, and only
enabled if the administrators knows what he/she is doing. ie could the
postinst script have:

if ! capabilities; then
  suidregister ...
else
  set capabilities.
endif

sorry, I am still confused over capabilities in general, so the above
may not really make sense ;-). For instance, I do not understand how
processes are initially assigned capabilities.

Please consider posting replies to debian-devel.
-- 
Brian May <bam@debian.org>