Re: implement-file-posix-capabilities.patch

[Andrew Morgan]

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