"Albert D. Cahalan" wrote:
>
> David L. Parsley writes:
> > 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 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.
He just said the kernel would be modified. NFS server support isn't
needed. Any support
would be in the client.
>
> 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.
The NFS client can't control whether or not the sticky bit is set on the
server, but
it CAN control whether or not it honours the sticky bit from the server.
Honouring the
sticky bit will require CAP_SETFCAP, and a flag. You would only allow it
if you know
that the server is capability-sticky smart. In order to mount any
filesystem capability-aware would require CAP_SETFCAP.
>
> 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!
How do you get the executable and it's sticky bit onto the
capability-aware Linux box?
It won't allow the sticky bit to be set when you write the file unless
your shell on
that box has CAP_SETFCAP. If this is the case, you are wasting your
time, you are
already root-equivalent.
-- Craig West Ph: (905) 821-8300 | It's not a bug, Pulse Microsystems Fx: (905) 821-7331 | It's a feature... 2660 Meadowvale Blvd, Unit #10 | acwest@echo-on.net Mississauga, Ont., Canada L5N-6M6 | craig@pulsemicro.com- 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/