On Fri 2008-01-04 21:54:06, Oliver Neukum wrote:
quoted text
> Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham:
> > Hi.
> > 
> > Oliver Neukum wrote:
> > > Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham:
> > >> Hi.
> > >>
> > >> Oliver Neukum wrote:
> > >>> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham:
> > >>>> On top of this, I made a (too simple at the moment) freeze_filesystems
> > >>>> function which iterates through &super_blocks in reverse order, freezing
> > >>>> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
> > >>>> currently allow for the possibility of someone mounting (say) ext3 on
> > >>>> fuse, but that would just be an extension of what's already done.
> > >>> How do you deal with fuse server tasks using other fuse filesystems?
> > >> Since they're frozen in reverse order, the dependant one would be frozen
> > >> first.
> > > 
> > > Say I do:
> > > 
> > > a) mount fuse on /tmp/first
> > > b) mount fuse on /tmp/second
> > > 
> > > Then the server task for (a) does "ls /tmp/second". So it will be frozen,
> > > right? How do you then freeze (a)? And keep in mind that the server task
> > > may have forked.
> > 
> > I guess I should first ask, is this a real life problem or a
> > hypothetical twisted web? I don't see why you would want to make two
> > filesystems interdependent - it sounds like the way to create livelock
> > and deadlocks in normal use, before we even begin to think about
> > hibernating.
> 
> Good questions. I personally don't use fuse, but I do care about power
> management. The problem I see is that an unprivileged user could make
> that dependency, even inadvertedly.

Other problem is that unprivileged user can do it with evil intent. So
called "denial-of-service" attack.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/