moosefs icon indicating copy to clipboard operation
moosefs copied to clipboard

[BUG] LXD UID issue

Open alpharde opened this issue 3 years ago • 9 comments

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?

alpharde avatar Dec 08 '22 22:12 alpharde

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?

xandrus avatar Dec 09 '22 11:12 xandrus

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

alpharde avatar Dec 10 '22 02:12 alpharde

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

xandrus avatar Dec 13 '22 11:12 xandrus

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 avatar Dec 19 '22 03:12 alpharde

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

alpharde avatar Jan 18 '23 20:01 alpharde

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.

zcalusic avatar Jan 18 '23 21:01 zcalusic

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

xandrus avatar Apr 25 '23 16:04 xandrus

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.

alpharde avatar Sep 26 '23 07:09 alpharde

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.

chogata avatar Oct 09 '23 11:10 chogata