Messages in this thread | | | Subject | Re: [PATCH] private mounts | From | Bryan Henderson <> | Date | Tue, 26 Apr 2005 11:55:28 -0700 |
| |
>On Tue, Apr 26, 2005 at 03:00:10AM -0700, Andrew Morton wrote: >> Not as thick as mine! Could someone please explain in small words what's >> wrong with an suid mount helper? > >Nothing per-se. What makes it bad is the context of a userland filesystem >where the actual filesystem operations in the mounted filesystem happen >in context of a non-privileged user.
How did the fact that the file access system calls involve user-controlled code come into this? I thought the FUSE kernel code already shielded the system from said code to everyone's satisfaction.
We've been talking, rather, about the namespace changes. The exact same issue exists with a non-userspace filesystem where the user controls the filesystem contents. For example, a filesystem on a user-supplied CD. A system administrator -- personally or through his setuid proxy -- might want to mount this CD for the benefit of some users/processes/whatever but not add it to the global namespace.
The issue of private mounts (mount = namespace change) would be good to resolve separately from any problem with bringing user space code into the kernel.
BTW, since Miklos said "mount helper" and others have said "mount wrapper," I think some of us may not be familiar with mount helpers. It's irrelevant to this discussion, but: util-linux 'mount' has a little-known feature wherein it can run a filesystem-type-specific program in a child process to do some of the mount function. A "mount wrapper" would be the opposite -- a filesystem-type-specific program that runs the generic 'mount' program in a child process.
-- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - 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/
| |