>>>>> "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 <[EMAIL PROTECTED]>
