Mount: use device directly if we are root. #195
Conversation
The mount function in mount_linux.go checks if we are uid 0 and, if so, tries to just do the mount directly. If that fails, then it will fall through to the fusermount path. I've tested this on a server of my own and it works. Signed-off-by: Ronald G. Minnich <[email protected]>
|
What is the benefit of this PR? Is there any performance gain? |
|
@chrislusf it allows to remove the runtime dependency on fusermount and the c-fuse package IFF the user is guaranteed to be root |
|
@zimbatm thanks for confirming! |
|
I like this patch. In my case I (initially) wanted to run this in a chroot, but couldn't because of the other binary missing. That's also a use case that is fixed by this patch. Having said that, I think there's even more room for improvement. At least in theory, it's possible for someone to not have uid 0, but still be allowed to mount devices (e.g. through CAP_SYS_ADMIN). You could also just attempt to mount it directly, and if that doesn't work, fallback on the external binary? |
|
I'd like to support this patch. It is definitly a gain of usabililty if we're independend on an external binary (even if for the uid=0 case only). The suggestions to first try it directly and then fallback to fusemount seem sensible. I'd like to see this patch in the mainline :) |
|
I like the general idea, but you really shouldn't be running as root (or CAP_SYS_ADMIN either). I'd like to see a complete story about that; go is not great at doing setuid (EDIT: I mean dropping privs, not chmod u+s), so I feel like doing this "right" will involve a bit more than just calling these APIs. |
The mount function in mount_linux.go checks if we are
uid 0 and, if so, tries to just do the mount directly.
If that fails, then it will fall through to the fusermount
path.
I've tested this on a server of my own and it works.
Signed-off-by: Ronald G. Minnich [email protected]