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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
