Re: [patch] kernel sysfs events layer

[Greg KH]

On Thu, Sep 16, 2004 at 04:10:08PM +0200, Herbert Poetzl wrote:
> On Wed, Sep 15, 2004 at 09:08:21PM -0700, Greg KH wrote:
> > On Thu, Sep 16, 2004 at 03:21:04AM +0200, Herbert Poetzl wrote:
> > > On Wed, Sep 15, 2004 at 05:38:39PM -0400, Robert Love wrote:
> > > > On Wed, 2004-09-15 at 14:34 -0700, Tim Hockin wrote:
> > > > 
> > > > > It's a can of worms, is what it is.  And I'm not sure what a good fix
> > > > > would be.  Would it just be enough to send a generic "mount-table changed"
> > > > > event, and let userspace figure out the rest?
> > > > 
> > > > "Can of worms" is a tough description for something that there is no
> > > > practical security issue for, just a lot of hand waving.  No one even
> > > > uses name spaces.
> > > 
> > > ah, sorry, that is wrong, we (linux-vserver)
> > > _do_ use namespaces extensively, and probably 
> > > other 'jail' solutions will use it too ...
> > 
> > Great.  
> > So, how do you handle the /sbin/hotplug call today?  
> 
> most of the time, not at all, but if, then in the
> 'initial' namespace where other userspace helpers
> are handled too (means on the host)

Ok, then you could handle the kevent message the same way, right?

> > How would you want to handle this kevent notifier?
> 
> if there was a notifier telling about mounts - real
> and virtual - then they would make sense _inside_
> the respective namespace they happen .. e.g.
> 
> usb-device attached: 
>   helper is called on host, and does some stuff
>   result is a mount of some device, which happens
>   on the host/initial namespace, notifier happens
>   there ...
> 
> process in namespace does --bind mount:
>   this might be interesting for the host too, but
>   probably it is more useful for the namespace
>   where it happened ... 

But in which namespace did it happen?  That's probaby the hard part to
determine, right?

thanks,

greg k-h
-
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/