On Sun, 11 Apr 1999, Pavel Machek wrote:
> Hi!
>
> > Geez, instead of overloading the meaning of 'setuid 0', let's just
> > use the sticky bit! I.e., sticky bit==cap flag:
>
> People/old programs do not realize that sticky bit means elevated
> privileges. Which is bad from backwards-compatibility point of
> view. I.e. I go to my sysadmin and ask him to set sticky on one of my
> executables. He'll do so.
Yes, this could be a problem, if the sysadmin doesn't know he's running a
capability enabled system where the sticky bit enables caps. Any sysadmin
worth his salt, though, should wonder why a user can't set his own sticky
bit, and why the user would ask it be done.
> > - To set the cap flag, a user (process) needs CAP_SETFCAP raised, and the
> > kernel (besides the normal fs checks) validates the cap headers as well
> > for legality. (this also applies to creating files with this flag raised;
> > i.e., through a copy operation)
>
> You do not want this kind of support in kernel. Believe me.
Got a better reason than 'believe me'? Like, 'there's no way to code that
into sys_chmod'?
> Better use
> setuid0 as marker (those are already immutable) and userspace suid
> program which implements your CAP_SETFCAP.
Here are the problems I have w/ marking w/ setuid0: screws up fs stuff; ls
et al. don't show a file is actually owned by another user when it should
be, and quotas don't work right, either; according to the vfs, root owns
all cap-enabled files; storing the 'real' uid and suid bit in the caps are
uglier, to me, than hacking the sticky bit. Marking with setuid0 just had
too many ugly repercussions that I found myself having to work around to
fully specify a sane structure for caps in elf headers.
Please give a little bit of thought to the sticky bit idea, and look at
the problems with it and solutions suggested.
Of course, if it's not possible to read the cap elf headers from the
sys_chmod call, that would be a certain killer...
> Pavel
> --
> I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
> Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
>
- --
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/