> Hi!
>
> > > Eh, what problem?
> >
> > The problem that setting inheritable bits is a non-priviledged operation
> > under the setuid0 scheme, and there is a LOT of power in the inheritable
> > bits. You are left wide open to trojan binaries, but a paranoid
> > sysadmin
>
> It is not a showstopper.
It's unnacceptable to _me_, since it doesn't conform to the POSIX spec.
(even if it _is_ a withdrawn draft.) I also still do not like the fact
that your using both the sticky bit and the uid to mark the file, and
Linux already has a use for these. This also is unnacceptable to _me_.
My current favorite solution is Ted Tso's idea of adding a new bit to ext2
attributes and using _that_ to mark a file with capabilities. I also
suggest a compatibility option settable under /proc to 'map' this bit over
the sticky bit during, say, package installation.
> Your capabilities do NOT prevent you from
> trojan horses. If you run program with uid=0, it does not need any
> special privileges to screw you up. [Hint: who is owner of /etc/passwd?]
I would _not_ design a system based on capabilities with uid(admin)=0; I'd
probably just use 1, or maybe 10 or something. With a real implementation
of capabilities, I can make admin whatever uid I want, and there's only
disadvantages to having admin own every file on the fs. Better, the admin
account should probably own _no_ files, since ruid passes to files
exec'ed.
cheers,
David
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/