lkml.org 
[lkml]   [2010]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Staging tree status for the .33 kernel merge
Quoting Ashwin Ganti (ashwin.ganti@gmail.com):
> On Sun, Jan 3, 2010 at 10:57 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > Quoting Greg KH (greg@kroah.com):
> > ...
> >> This means, unless someone steps up and starts doing real work (not
> >> trivial spelling fixes) on the following drivers, they will be removed
> >> in the future kernel releases.
> >>
> >> ?- arlan, netwave, strip, wavelan - wireless drivers mentioned above
> >> ? ?that are on the way out. ?Slated for removal in 2.6.35
> >> ?- hv - Microsoft Hyper V drivers. ?The developers again seem to have
> >> ? ?disappeared, this is getting old. Slated for removal in 2.6.35
> >> ?- p9auth - this will be removed in .34 unless someone steps up.
> >
> > I think I've decided to try to push it. ?I'm working with some patches
> > at git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-cr.git
> > (branch p9auth.jan3.4 is latest). ?I'll send patches as I feel they
> > are ready - so far they pass testcases, but are too new for me to
> > feel I should push them today.
>
> Thanks Serge!
>
> It is useful to continue to have this driver in the tree as there a
> few other people as well who have shown interest in using this. I have
> been recently contacted by guys at Glendix (http://www.glendix.org/)
> who have started looking at using this driver.
>
> >
> > Ashwin, I'm curious whether you'd think the last patch
> > (http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/sergeh/linux-cr.git;a=commitdiff;h=1662ba777140a39c21a9b647459d2deab8ffe1ca)
> > would be a problem with any userspace - but I assume there is no
> > legacy userspace to really worry about?
>
> There is no legacy user space support yet for Linux. This should be
> fine in that sense.
> I still need to look at the patches in detail though but what is the
> motivation for this change?

Well, to have a login daemon be unprivileged, it needs some way to
set groups without CAP_SETGID. I was playing with some toy frontend
and backend (i.e. login and factotum) code and this seemed a nice
simple way to do it.

> Please also cc rsc@swtch.com and ericvh@gmail.com as well when you
> send out these patches for review.

Will do, thanks.

> > Apart from plenty more cleanups, another more fundamental issue to
> > address is how to stop unused caphash entries from piling up in
> > memory. ?Put a timeout on them? ?Let privileged userspace list and
> > occasionally delete them? ?Associate a target task with each entry,
> > where either the task or its decendent can use the capability, but
> > if the task dies we free the caphash entry?
>
> So, there are a couple of options here (I favor the second approach):
> 1. We can add a timer to expire the capabilities.
> 2. Add a creation time stamp to every capability. Whenever a
> capability is used (i.e. written to /dev/caphash) we can go through
> the list in the kernel and reap the ones whose time stamp has expired.
> We can optimize the data structure later to make this faster.

Ok, I'll do that when I get a chance, do some more testing, and send
out in the next two weeks.

thanks,
-serge


\
 
 \ /
  Last update: 2010-01-04 18:27    [W:0.039 / U:0.988 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site