Re: implement-file-posix-capabilities.patch

Andrew Morgan
2007-07-04T21:30:26Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Serge E. Hallyn wrote:
> 1. Exactly Andrew describes. Once userspace switches to a new cap
> format, an older kernel simply won't support them

Mmm. Let me see. I think I prefer this one! :-)

> 2. As Andrew describes, but also encode the version number into the
> capability name, i.e. security.capability.v3. Now userspace can
> optionally tack on more than one capability version to be backward
> compatible.

If you have a significant legacy of use of earlier versions, I guess
this makes sense. However, given the experimental nature of this support
(it will be a while before the user space support for this is
secure/robust), I'm not all that concerned about legacy support.

> 3. Somewhat different than Andrew describes. We mandate that any
> capability version N+1 consist of
>
> struct vfs_cap_data {
> __u32 magic;
> capability_version_1;
> capability_version_2;
> ...
> capability_version_N;
> capability_version_N+1;
> };

Ugh. I don't like this. It presumes that the kernel will get more and
more complicated over time. Please don't do this one.

> Or, for brevity,
>
> struct vfs_cap_data {
> __u32 first_magic;
> __u32 last_magic;
> capability_version_first;
> ...
> capability_version_last;
> };
>
> 4. Stick to the current plan, where switching to 64-bit caps will be
> done as
>
> struct vfs_cap_data_disk {
> __le32 version;
> __le32 data[]; /* eff[0], perm[0], inh[0], eff[1], ... */
> };

While asserting that it is more flexible etc., no one has yet actually
given an example of where fE being richer than a simple binary helps
anything. Until I see an example, I'm going to hold the position that
this is needless "complexity".

Cheers

Andrew

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjBFXmwytjiwfWMwRAofJAKCXX2GkN39o45fCQmxpNpZIEVH8EgCeLaDy
AoWZNj/1MqT7oayabxUhIn8=
=OSBu
-----END PGP SIGNATURE-----