I have a 2.2 kernel right here, and it does NOT require CAP_SETFCAP to
change the sticky bit. Oh, you plan to patch the kernel? Of course you
do, but you can't ensure that every NFS server in the world will be
patched as you wish.
The NFS client has no control over this. Using the sticky bit as a
flag is just absurdly bad. You might as well use the world-write bit.
Imagine a Linux distribution that had this misfeature. It gets installed
on some new systems on the network. I sit down at my old Linux box,
make a nice executable, telnet to a new box, and do bad things. Yow!
> If 'doesn't implement capabilities correctly' isn't a showstopper for you,
We currently have a 'doesn't implement capabilities correctly' situation,
for many definitions of 'correctly'. (no on-disk support)
The setuid-root solution is a large improvement. Good. I'll not worry
that it doesn't offer all theoretically possible features.
I'll certainly prefer the setuid-root solution over the MASSIVE SECURITY
HOLE caused by trusting remote executables with the sticky bit set.
The intent is to reduce security holes I hope, not to add big holes.
> 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.
That is beauty, not ugliness. I can have 4 UID values if I want.
> I'll just wait for caps in the fs metadata, which will at least work
> correctly although requiring updating a bunch of tools.
Your "correctly" does not include NFS, iso9660, etc.
Considering how many tools would break, you might as well change your
operating system. How about DG-UX with the B2 security option?
-
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/