Messages in this thread | | | Date | Mon, 16 Mar 2009 17:59:40 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? |
| |
Quoting J. Bruce Fields (bfields@fieldses.org): > On Mon, Mar 16, 2009 at 12:04:33PM -0500, Serge E. Hallyn wrote: > > Quoting J. Bruce Fields (bfields@fieldses.org): > > > If filesystem permissions similarly never affected the ability to create > > > device nodes, that might also be an argument against including > > > CAP_MKNOD, but it would be interesting to know the pre-capabilities > > > behavior of a uid 0 process with fsuid non-0. > > > > The sentiment rings true, but again since before capabilities, privilege > > was fully tied to the userid, the question doesn't make sense. Either > > you had uid 0 and could mknod, or you didn't and couldn't. And that is > > the behavior which we unfortunately have to emulate when > > !issecure(SECURE_NOROOT|SECURE_NOSUIDFIXUP). > > The historical behavior of setfsuid() is still interesting, though. > >From a quick glance at Debian's code for the (long-neglected) userspace > nfsd server, it looks like it depends on setfsuid() and the kernel to > enforce permissions for operations (including mknod). Might be
Sorry, do you mean that it would expect setfsuid(0) to allow a task to do mknod, and setfsuid(500) to disable it?
Actually I guess for mknod, that is the question we can answer with the a 2.1.x tree: which uid did mknod check?
Ah, answer is... fsuid!
> interesting to confirm whether it has the same problem, and if so, > whether that was a problem introduced with some capability changes or > whether it always existed. > > --b.
| |