lkml.org 
[lkml]   [2010]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] p9auth: add p9auth driver
Quoting Eric W. Biederman (ebiederm@xmission.com):
> ron minnich <rminnich@gmail.com> writes:
>
> > On Fri, Apr 23, 2010 at 8:36 PM, Serge E. Hallyn <serue@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


\
 
 \ /
  Last update: 2010-04-25 05:29    [W:0.101 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site