p9auth: add p9auth driver
in [Kernel]
|
Prev: p9auth: add CAP_GRANT_ID to authorize use of /dev/caphash
Next: firmware loader: embed device into firmware_priv structure
From: Eric W. Biederman on 24 Apr 2010 14:10 ron minnich <rminnich(a)gmail.com> writes: > On Fri, Apr 23, 2010 at 8:36 PM, Serge E. Hallyn <serue(a)us.ibm.com> wrote: > >> An fs actually seems overkill for two write-only files for >> process-related information. Would these actually be candidates >> for new /proc files? >> >> /proc/grantcred - replaces /dev/caphash, for privileged >> tasks to tell the kernel about new setuid >> capabilities >> /proc/self/usecred - replaces /dev/capuse for unprivileged >> tasks to make use of a setuid capability > > An fs is fine. > > To relate this to Plan 9, where it all began, might be useful. There's > no equivalent in Plan 9 to Linux/Unix devices of the major/minor > number etc. variety. In-kernel drivers and out-of-kernel servers both > end up providing the services (i.e. file name spaces) that we see in a > Linux file system. So the Plan 9 driver for the capability device > really does match closely in function and interface to a Linux > kernel-based file system. > > Hence, making devcap a file system is entirely appropriate, because it > best fits the way it works in Plan 9: a kernel driver that provides > two files. > > It's pretty easy to write a Linux VFS anyway, so it makes sense from > that point of view. > > Eric, that was a great suggestion. A fs provides user space policy control of naming. I.e. where the two files go. That can also be a very big deal. Especially when files are writable. You have no idea how much I am frustrated by sysfs right now, because it does not provide userspace policy control and instead mandates a sometimes inappropriate naming convention. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Serge E. Hallyn on 24 Apr 2010 23:30
Quoting Eric W. Biederman (ebiederm(a)xmission.com): > ron minnich <rminnich(a)gmail.com> writes: > > > On Fri, Apr 23, 2010 at 8:36 PM, Serge E. Hallyn <serue(a)us.ibm.com> wrote: > > > >> An fs actually seems overkill for two write-only files for > >> process-related information. ??Would these actually be candidates > >> for new /proc files? > >> > >> ?? ?? ?? ??/proc/grantcred - replaces /dev/caphash, for privileged > >> ?? ?? ?? ?? ?? ?? ?? ??tasks to tell the kernel about new setuid > >> ?? ?? ?? ?? ?? ?? ?? ??capabilities > >> ?? ?? ?? ??/proc/self/usecred - replaces /dev/capuse for unprivileged > >> ?? ?? ?? ?? ?? ?? ?? ??tasks to make use of a setuid capability > > > > An fs is fine. > > > > To relate this to Plan 9, where it all began, might be useful. There's > > no equivalent in Plan 9 to Linux/Unix devices of the major/minor > > number etc. variety. In-kernel drivers and out-of-kernel servers both > > end up providing the services (i.e. file name spaces) that we see in a > > Linux file system. So the Plan 9 driver for the capability device > > really does match closely in function and interface to a Linux > > kernel-based file system. > > > > Hence, making devcap a file system is entirely appropriate, because it > > best fits the way it works in Plan 9: a kernel driver that provides > > two files. > > > > It's pretty easy to write a Linux VFS anyway, so it makes sense from > > that point of view. > > > > Eric, that was a great suggestion. > > A fs provides user space policy control of naming. I.e. where the two files go. > That can also be a very big deal. Especially when files are writable. > > You have no idea how much I am frustrated by sysfs right now, because > it does not provide userspace policy control and instead mandates a > sometimes inappropriate naming convention. > > Eric Well I'm not convinced that it's a worthwhile tradeoff for polluting /proc/filesystems and needing yet another fs mounted in each container, but a preliminary working version using an fs is at http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/sergeh/linux-cr.git;a=shortlog;h=refs/heads/p9auth.apr24.2 I'll do some cleanup before sending it out. Eric, I'd said that the device-based version was namespace-aware, but that meant that you could on grant and use capabilities in your own user namespace. I suppose now that it's an fs we can do better semantics, where each user ns can mount its own p9auth, and anyone with CAP_GRANT_ID targeted at some user ns (i.e. root in a user_ns or the creator of a user_ns) can grant ids to that user ns. Though I'm not sure that's a feature anyone would ever use, and I do like the simplicity of just having one sb. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |