On Thu, 15 Apr 1999, Albert D. Cahalan wrote:
> David L. Parsley writes:
>
> > Well, the stickybit/immutable solution has been modified so that it can
> > be compatible with local fs tools, but is still not completely secure with
> > remote fs's. Still, nfs at least should understand the sticky bit, and if
> > you can trust the security of the sticky bit on the remote system, it _is_
> > possible to use caps with a mount option.
>
> Ugh. Immutable does not survive backup and restore. The sticky bit
> is not even secure on a Linux 2.2 server.
Then you haven't been paying attention, Albert. After the modification, a
2.2 kernel will interpret 'chmod +t' as 'capability enable'; this will
require the current process has CAP_SETFCAP, and on success will set
_both_ sticky and immutable on a local fs. (or just sticky on remote).
Otherwise neither is set.
> > I hope you're both following my thread with Pavel Machek, where I have
> > shown showstopper problems with the setuid0 scheme. It just doesn't
> > implement capabilities, but rather mutates them badly in order to work
> > with the setuid0 scheme.
>
> Not so fast. You didn't discover any showstopper problems.
If 'doesn't implement capabilities correctly' isn't a showstopper for you,
then you are correct. Of course, I'll expect to hear the new
specification for capabilities, and how they are to be applied in
real-world situations. It would also be nice if they provided as flexible
a model as the current spec. So far, it seems that correctness and
flexibility are a whole lot less important than using the stupid setuid0
flag, which also has the severe ugliness of storing the uid and suid bit
in the headers.
Like I said, good luck getting this in the kernel. And no, I could care
less if anybody thinks the stickybit solution would never go in, either.
I'll just wait for caps in the fs metadata, which will at least work
correctly although requiring updating a bunch of tools.
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/