[Feature Request] Add allow_root mount option

[andreyrd]

There is already allow_other in gocryptfs, but there is also a much safer allow_root option available in fuse that allows only the user who created the mount and root to access it. One particular use case for this is when passing the decrypted filesystem through to Docker, whose daemon runs as root, without opening up the decrypted filesystem to ALL users.

[proofrock]

I came to open an issue about this :-) How hard would it be, and would you consider a possible PR for this? Is it doable by a first-time contributor?

[rfjakob]

Makes sense. Yes this is good for a first PR.

[proofrock]

@rfjakob I added the config --allow-root, enabled user_allow_other in fuse.conf and passed the option to the underlying go-fuse in the MountOptions.Options array. But it says

/usr/sbin/fusermount3: unknown option 'allow_root'

which by the way is the same when specifying -o allow_root. It seems that fuse itself doesn't recognize the flag, which is strange. I am running what should be the latest version of fuse3 (3.16.2).

I'll try some more in the evening (CET). Out of your mind can you think of something?

[proofrock]

bazil/fuse#144

It seems that the situation is quite complicated. They seem to suggest to just allow_other and then limiting the UID (to 0) at filesystem level.

[rfjakob]

Oh. From https://man7.org/linux/man-pages/man8/mount.fuse3.8.html : *libfuse-specific mount options:* These following options are not actually passed to the kernel but interpreted by libfuse. They can be specified for all filesystems that use libfuse: *allow_root* This option is similar to *allow_other *but file access is limited to the filesystem owner and root. This option and *allow_other *are mutually exclusive.

…

On Tue, 4 Mar 2025, 13:06 Germano Rizzo, ***@***.***> wrote: bazil/fuse#144 <bazil/fuse#144> It seems that the situation is quite complicated. They seem to suggest to just allow_other and then limiting the UID (to 0) at filesystem level. — Reply to this email directly, view it on GitHub <#899 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGA74XSB7BMUZLHIMPIUL2SWJMFAVCNFSM6AAAAABXW5JCQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJXGMZDCOJRGI> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: proofrock]*proofrock* left a comment (rfjakob/gocryptfs#899) <#899 (comment)> bazil/fuse#144 <bazil/fuse#144> It seems that the situation is quite complicated. They seem to suggest to just allow_other and then limiting the UID (to 0) at filesystem level. — Reply to this email directly, view it on GitHub <#899 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGA74XSB7BMUZLHIMPIUL2SWJMFAVCNFSM6AAAAABXW5JCQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJXGMZDCOJRGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[proofrock]

Oh. From https://man7.org/linux/man-pages/man8/mount.fuse3.8.html :
[snip]

Thanks! I see that you use go-fuse, which says

Performance that is competitive with libfuse.

So it doesn't use libfuse, I think. That confirms that, since libfuse implements allow_root by itself, gocryptfs cannot use it. And this clarifies the situation.

So you think it's worth the effort to implement a sort of "uid whitelist" to achieve the same effect? So that allow_root is allow_others+whitelist(0), so to speak. Maybe you can point me to the code where to put the whitelist check? Or I'll just do my homeworks ;-)

[rfjakob]

Forcing the root directory of the mount to 0700 permissions should be enough, I'll check where to add it

…

On Tue, 4 Mar 2025, 15:52 Germano Rizzo, ***@***.***> wrote: Oh. From https://man7.org/linux/man-pages/man8/mount.fuse3.8.html : [snip] Thanks! I see that you use go-fuse, which says Performance that is competitive with libfuse. So it doesn't use libfuse, I think. That confirms that, since libfuse implements allow_root by itself, gocryptfs cannot use it. And this clarifies the situation. So you think it's worth the effort to implement a sort of "uid whitelist" to achieve the same effect? So that allow_root is allow_others+ whitelist(0), so to speak. Maybe you can point me to the code where to put the whitelist check? Or I'll just do my homeworks ;-) — Reply to this email directly, view it on GitHub <#899 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGA77SLGWNJUIVHLUQT6D2SW4Z7AVCNFSM6AAAAABXW5JCQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJXHEYTIOBZGA> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: proofrock]*proofrock* left a comment (rfjakob/gocryptfs#899) <#899 (comment)> Oh. From https://man7.org/linux/man-pages/man8/mount.fuse3.8.html : [snip] Thanks! I see that you use go-fuse, which says Performance that is competitive with libfuse. So it doesn't use libfuse, I think. That confirms that, since libfuse implements allow_root by itself, gocryptfs cannot use it. And this clarifies the situation. So you think it's worth the effort to implement a sort of "uid whitelist" to achieve the same effect? So that allow_root is allow_others+ whitelist(0), so to speak. Maybe you can point me to the code where to put the whitelist check? Or I'll just do my homeworks ;-) — Reply to this email directly, view it on GitHub <#899 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGA77SLGWNJUIVHLUQT6D2SW4Z7AVCNFSM6AAAAABXW5JCQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJXHEYTIOBZGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>