How does allow_other work (how are the real/effective UID of the user space file system changed)

457 views
Skip to first unread message

chris....@gmail.com

unread,
Mar 13, 2014, 5:39:01 PM3/13/14
to osxfus...@googlegroups.com
Hi everybody,

I am wondering how the allow_other mount option in (OSX)Fuse actually works? What I am especially interested is how/where the real and effective user ID of the userspace file system process are changed? Is this done in the Kernel or is this done in the FUSE library, which means inside the file system daemon process? I quickly grep'ed through the OSXFuse sources but I could neither find in the Kernel sources where the UIDs of the task_struct are changed nor could I see a set(e)uid() call in the user space code.

The reason why I am interested in this is because I am wondering whether an unprivileged process mounted with allow_other as user A could be used to fully impersonate user B. This means that although the process is mounted by user A, the file system completely acts as user B when this user accesses the file system. I believe if the user ID changes occur in the filesystem user space process, this will not work. (And some tests also showed me that this is possible only if the process is mounted by root with the allow_other flag).

Thanks for any information or some pointers to where I could look this up in the OSXFuse source code.

Christian.

chris....@gmail.com

unread,
Mar 14, 2014, 4:10:06 AM3/14/14
to osxfus...@googlegroups.com
O.k. I did some further grep'ing and found that it seems as if the impersonation is  done in user space via the threadid module (lib/modules/threadid.c).
In there the UID values are changed with the pthread_setugid_np call according to the UIDs of the calling process which are available in the FUSE context struct (fuse_get_context()).

Christian.

chris....@gmail.com

unread,
Mar 18, 2014, 3:34:44 AM3/18/14
to osxfus...@googlegroups.com
You have to set the osxfuse.tunables.admin_group key with sysctl to a group that unprivileged users belong to.
This is detailed here: http://code.google.com/p/macfuse/wiki/OPTIONS (just replace "macfuse" with "osxfuse" in the mentioned sysctl keys).
So, for allowing all users to do unprivileged mounts with allow_other you could grant everyone (group-ID 12) this privilege by doing:

# sysctl -w osxfuse.tunables.admin_group=12
osxfuse.tunables.admin_group: 0 -> 12


Just for checking back that the change has worked:
# sysctl osxfuse.tunables.admin_group
osxfuse.tunables.admin_group: 12


Christian.


On Friday, March 14, 2014 1:07:18 PM UTC+1, Michael Ryan wrote:
My experience has been that if you enable the allow_other mount option when trying to mount a file system from an unprivileged account, osxfuse will throw an exception and the mount will be inaccessible. We have a lot of customers who try to enable that option when using our product from a Standard Mac account and it fails to mount. I can't recall what the mount exception was though.

Michael

Michael Ryan

unread,
Mar 14, 2014, 8:07:18 AM3/14/14
to osxfus...@googlegroups.com
My experience has been that if you enable the allow_other mount option when trying to mount a file system from an unprivileged account, osxfuse will throw an exception and the mount will be inaccessible. We have a lot of customers who try to enable that option when using our product from a Standard Mac account and it fails to mount. I can't recall what the mount exception was though.

Michael



On Thursday, March 13, 2014 5:39:01 PM UTC-4, chris....@gmail.com wrote:
Reply all
Reply to author
Forward
0 new messages