Re: implement-file-posix-capabilities.patch

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Andrew Morgan (morgan@kernel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Serge E. Hallyn wrote:
> >> Does that explain it?
> > 
> > Yes, thanks, but then it still could come in handy to have fE be a full
> > bitset, so the application gets some eff caps automatically, while
> > others it has to manually set...
> 
> [We touched on this a number of emails back.]
> 
> If an application is capability aware, it can manipulate its own
> capabilities and should have fE=0.
> 
> If an application is not capability aware, it needs to have *all* of its
> capabilities enabled at exec() time. Otherwise, it won't work.
> 
> The only reason for having an fE bitmap is to allow a capability-aware
> program (you really trust to do its privileged operations carefully) to
> be lazy and get some of its capabilities raised for free. Perhaps you
> can clarify why this is a desirable thing? :-)

Sure - because it doesn't hurt anything, someone just *might* find it
useful one day, and mostly the three bitmaps just look a lot cleaner to
me than hiding a bit inside the version field.  There are a *few* people
using this, and so a complete switch in format for no actual net gain
seems wrong.  If we want to fake fE to the user as being one bit we can
do that through the setfcaps/getfcaps programs.

There also are prior examples of doing it this way (i.e. Olaf Dietsche's
implementation)

OTOH I don't deny implementing it fully as you describe seems to make
the intent of the code clearer to readers and maintainers.

I guess maybe I'll give it a go and see what turns out.

thanks,
-serge
-
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/