Messages in this thread | | | Date | Thu, 12 Jul 2007 15:31:12 +0000 | From | Pavel Machek <> | Subject | Re: malicious filesystems (was Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway) |
| |
Hi!
> > So you want me to handle _malicious_ filesystems now? > > > > That should be easy... :-). You already have nasty deadlocks in FUSE, > > and you solve them by "root can echo 1 > abort"... so allow me the > > same possibility. > > > > We can tell fused we are freezing, and if all the requests are not > > serviced within, say, 30 seconds, we call the filesystem malicious and > > do echo 1 > abort. > > > > Not ideal, but neither is allowing malicious filesystems in the first > > place... > > Actually there's also a non-malicious case in which waiting for > requests to finish won't work: when one fuse filesystem is accessing > another. > > Since we are blocking new fuse requests, that might block a fuse > daemon, which in turn makes it impossible to finish the pending > request.
Hmm, yes, this is ugly. But will it hurt? We'll just wait for number of active fuse requests to go down to 0 before proceeding. It may still livelock on system with busy fused-s, but we'll detect that with timeout, and I believe it is 'don't do that' situation.
> And this is not at all theoretical, I know that encfs is used over > various other fuse filesystems like sshfs or ntfs-3g. > > Yeah, stacking userspace filesystems could be done entirely in > userspace, and I'm actually working on that (with fuse-2.7.0 already > supporting some basic stacking).
Great.
> But the point is, that the "wait for fuse to quiescence" hack would > not work in todays environment.
Ok, I'll just blame fuse here. 'You have to write to /sys files for SIGKILL to work' is not funny. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
| |