[BUG] LXD UID issue

[alpharde]

System information

MooseFS master 023198e
Debian 11

Describe the problem you observed.

I'm getting permission errors as root inside a unprivileged lxd container with swapped uids.

Outside container:

root@srv01:/mnt/mfs/craft/backups# ls -lah
total 3.7G
drwxr-xr-x 2 101000 101000 2.9M Dec  8 19:05 .
drwxr-xr-x 3 100000 100000 2.9M Dec  8 19:04 ..
-rw-r--r-- 1 101000 101000 756M May  3  2022 craft20220503173000.zip

Inside container:

bash-5.1# ls -lah
total 3.7G
drwxr-xr-x    2 craft craft    2.9M Dec  8 22:05 .
drwxr-xr-x    3 root  root     2.9M Dec  8 22:04 ..
-rw-r--r--    1 craft craft  755.6M May  3  2022 craft20220503173000.zip

touch tmp as root on host works fine.
touch tmp inside container as user craft (1000/101000) also works.
touch tmp inside container as root (0/100000) results in Permission denied.

Is this an issue with MooseFS or maybe I'm missing some configuration?

[xandrus]

Hello,
Can you tell us more about this configuration?

Are you mounting the MFS client inside the container or is the whole container stored on a MooseFS cluster?

[alpharde]

mfs mount is running on the host. I just passed a single directory to the container, the container itself is running on the host.

[xandrus]

OK, can you share your lxc.idmap and root mapping from /etc/subuid and /etc/subgid files?

I suspect that the unprivileged lxc container outside maps root to uid:100000 and guid:100000, and the user craft maps to uid:101000 and guid:101000 . That is why, the craft user has permissions to the backups folder, while the fake "root" does not.

root@srv01:/mnt/mfs/craft/backups# ls -lah
total 3.7G
drwxr-xr-x 2 101000 101000 2.9M Dec  8 19:05 .
drwxr-xr-x 3 100000 100000 2.9M Dec  8 19:04 ..

You can always check what is going on inside MooseFS client by executeing this command in a separate terminal:
cat /mnt/mfs/.oplog

[alpharde]

root@srv01:~# cat /etc/subuid
_lxd:100000:10000001
root:100000:10000001
root@srv01:~# cat /etc/subgid
_lxd:100000:10000001
root:100000:10000001

lxc.idmap is unset, I believe lxd grabs whatever values in subuid and subgid.

I suspect that the unprivileged lxc container outside maps root to uid:100000 and guid:100000, and the user craft maps to uid:101000 and guid:101000 . That is why, the craft user has permissions to the backups folder, while the fake "root" does not.

Seems to be the case.

[alpharde]

Any updates on this? It prevents me from using moose on K8S/docker as well.

[zcalusic]

Have you uncommented user_allow_other in /etc/fuse.conf?

Maybe also allow_other mount option is missing?

Try some of those... something may help.

[xandrus]

Hi,

I would like to add one aspect to this thread.
You can try to "disable" ownership for a particular path using the MooseFS eattr noowner flag.
The noowner attribute means that any user (except root) will see the object as their own.

So for example:
mfsseteattr -f noowner /mnt/mfs/lxc

[alpharde]

I would rather not disable access control like this...
Can I have a simple/hacky option to define which uids and gids should moosefs regard as root?
This would most likely solve my problem.

[chogata]

I'm afraid there is no option for converting specific uids to other uids right now in MooseFS. It is on the todo list though. But currently your only options are to switch off control for specific files/directories or whole exports.