Re: Filesystem Capabilities in 2.6?

Linus Torvalds (torvalds@transmeta.com)
Sat, 2 Nov 2002 21:39:39 -0800 (PST)


On Sun, 3 Nov 2002, Alexander Viro wrote:
>
> If you want that place to retain some capabilities -
> s/nosuid/capmask=.../ in the above.

Ok, I get your example, but nope, I don't think it will work.

Why? Because then the suid check will work, and not only will you get all
capabilities (_if_ the suid was root), you will also have changed your ID
(since that was how you got enough capabilities to be able to mask them
off).

Which you do _not_ want to do. You just want the capabilities, you don't
necessarily want to run as somebody else (or if you do, that "somebody
else" might well be "nobody"). So suid vs capabilities are different: you
may even want them to be complementary.

In other words, it would actually make perfect sense to have

-r-sr-sr-x 1 nobody mail 451280 Apr 8 2002 /usr/bin/sendmail

mount --bind --capability=chown,bindlow /usr/bin/sendmail /usr/bin/sendmail

ie have it be suid nobody:mail (to _remove_ any vestige of normal user
rights but give it write permission on the mail directory), and then
separately giving it specific capabilities to allow it to chown files it
creates and bind to port 25).

(yeah, maybe that's a bad example, I dunno what sendmail actually wants to
do).

In the above, the suid'ness of the binary is totally independent of the
capabilities: the suid bits don't have any meaning for the capability set,
since it's not about root, but the suid bits _do_ have meaning from a
filesystem permission standpoint.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/