Understanding unix auth in FUSE mount

I observed some unexpected behaviors when using unix authentication in EOS FUSE mount. I have a user named laf on my MGM-QDB-FST co-located virtual machine for testing:

> grep laf /etc/passwd
laf:x:1000:1000:laf:/home/laf:/bin/zsh

and the EOS vid config is:

> eos vid ls
publicaccesslevel: => 1024
sudoer                 => uids()
tokensudo              => always
unix:"<pwd>":gid => root
unix:"<pwd>":uid => root

and the FUSE config is:

{"hostport": "localhost", "auth": {"shared-mount": 1, "unix": 1, "unix-root": 0, "sss": 1}}

With the above configs, when using the laf user, the eos whoami output is expected:

laf> eos whoami
Virtual Identity: uid=1000 (99,1000) gid=1000 (99,1000) [authz:unix] host=localhost domain=localdomain

and commands like eos touch and eos chown work with privilege limitations as expected, but if I am in the FUSE mount directory, I actually become root user:

laf> ls -alh /eos/dev/test
total 13M
drwxrwxr-x. 2 root root 4.0K Oct  5 16:17 .
drwxrwxr-x. 2 root root 4.0K Oct  5 15:33 ..

laf> echo "test" > /eos/dev/test/test.txt
laf> ls -alh /eos/dev/test
total 13M
drwxrwxr-x. 1 root root 4.0K Oct  5 16:32 .
drwxrwxr-x. 2 root root 4.0K Oct  5 15:33 ..
-rw-r--r--. 1 root root    5 Oct  5 16:33 test.txt

and I can chown or chmod on anything, which is definitely unexpected. Is this behavior due to my misconfiguration or misunderstanding? How can I configure unix auth for FUSE mount correctly?

Hi Anfeng,
this is an artefact, that you have the client sitting on the namespace node itself and connecting to localhost. Try the same connecting from an external VM. But I will have a look to change that, since it is indeed ‘not what you would expect’.

I have created a ticket about that functionality:

https://its.cern.ch/jira/browse/EOS-5850

Hi Andreas,

Thanks very much for your reply! However, I am still experiencing unix authentication problems when connecting from an external VM.

On the MGM-QDB-FST co-located node whose IP address is 192.168.222.129, the VID config is still:

root@192.168.222.129> eos vid ls
publicaccesslevel: => 1024
sudoer                 => uids()
tokensudo              => always
unix:"<pwd>":gid => root
unix:"<pwd>":uid => root

Then I created another virtual machine whose IP address is 192.168.222.128, installed EOS and FUSE mounted EOS with the config below:

root@192.168.222.128> cat /etc/eos/fuse.eosdev.conf
{"hostport": "192.168.222.129", "auth": {"shared-mount": 1, "unix": 1, "unix-root": 0, "sss": 1}}

root@192.168.222.128> eosxd -ofsname=eosdev
# fsname='eosdev'
# -o allow_other enabled on shared mount
# -o big_writes enabled
# JSON parsing successful
# no config file for local overwrites
# enabling swapping inodes with md-cache in '/var/cache/eos/fusex/md-cache/'
warning: sss keytabfile '/etc/eos/fuse.sss.keytab' does not exist - disabling sss/oauth2
# File descriptor limit: 524288 soft, 524288 hard
# allowing max read-ahead buffers of 134217728 bytes
# allowing max write-back buffers of 134217728 bytes
# Disabling nagle algorithm (XRD_NODELAY=1)
# Setting MALLOC_CONF=dirty_decay_ms:0

Then I switched to user laf and tried the authentication:

laf@192.168.222.128> id
uid=1000(laf) gid=1000(laf) groups=1000(laf),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

laf@192.168.222.128> export EOS_MGM_URL=root://192.168.222.129
laf@192.168.222.128> eos whoami
Virtual Identity: uid=1000 (99,1000) gid=1000 (99,1000) [authz:unix] host=[::ffff:192.168.222.128] domain=168.222.128]

laf@192.168.222.128> ls -alh /eos/dev/test
drwxrwxr-x. 2 root root 4.0K Oct  8 15:29 .
drwxrwxr-x. 2 root root 4.0K Oct  5 15:33 ..

laf@192.168.222.128> echo "test" > /eos/dev/test/test.txt

laf@192.168.222.128> ls -alh /eos/dev/test
drwxrwxr-x. 1 root root 4.0K Oct  8 15:43 .
drwxrwxr-x. 2 root root 4.0K Oct  5 15:33 ..
-rw-r--r--. 1 root root    0 Oct  8 15:43 test.txt

laf@192.168.222.128> chmod +x /eos/dev/test/test.txt
laf@192.168.222.128> ls -alh /eos/dev/test
drwxrwxr-x. 1 root root 4.0K Oct  8 15:47 .
drwxrwxr-x. 2 root root 4.0K Oct  5 15:33 ..
-rwxr-xr-x. 1 root root    0 Oct  8 15:47 test.txt

As you can see above, though eos whoami tells me that I am laf, I am still root in the FUSE mount.

Ah ok,
so the problem is, that you should NOT enable unix authentication !!!

Global Unix authentication is first unsafe. We don’t use that anywhere in production like that.

First do:
eos vid disable unix

Every machine, which you allow to map from UID/GID to a user in EOS you should add using:

eos vid add gateway clienthost.clientdomain unix

This uses a different mapping mechanism than enabling UNIX globally and maps to the user on the client machine (by default not allowing root). UNIX globally uses the ID of the process talking to EOS, which in your case probably runs as root, since it is the shared FUSE mount daemon. I probably can also change that behaviour, it would be probably more convenient to just enable UNIX for this cases and have this working also for FUSE.

If you cannot specify your client hosts (because they are dynamic or too many), it is better to use an ‘sss’ key between client and server. I need to add that to the documentation.

Maybe give it a try using the ‘gateway’ configuration and disabling global unix mapping. I will look into having this also as expected when one just enables UNIX globally.