CS01-HS Posted January 11, 2021 Share Posted January 11, 2021 (edited) I created an unRAID user limited (id 1006) which I'm trying to use to limit write permission in docker containers that support PUID. Can anyone explain the following behavior? Launch EmbyServer shell with user nobody # docker exec -u 99 -it EmbyServer sh Create a file writable only by nobody / $ touch /media/TV/x / $ chmod go-w /media/TV/x / $ ls -l /media/TV/x -rw-r--r-- 1 99 root 0 Jan 11 11:35 /media/TV/x Launch sonarr shell with user limited # docker exec -u 1006 -it sonarr sh Confirm I'm limited (id 1006): $ whoami abc $ grep abc /etc/passwd abc:x:1006:100::/config:/bin/false Check permissions on the newly-created file: (NOTE: /media/TV in EmbyServer and /tv in sonarr map to the same host path.) $ ls -l /tv/x -rw-r--r-- 1 99 root 0 Jan 11 06:35 /tv/x So the file should not be writable by current user abc - and yet: $ rm /tv/x $ ls -l /tv/x ls: cannot access '/tv/x': No such file or directory abc can delete it. What's going on? Edited January 11, 2021 by CS01-HS Quote Link to comment
itimpi Posted January 11, 2021 Share Posted January 11, 2021 Have you checked the permissions on the containing directory? I think that ‘wx’ permissions allows deleting files within the directory. 1 Quote Link to comment
CS01-HS Posted January 11, 2021 Author Share Posted January 11, 2021 (edited) 18 minutes ago, itimpi said: Have you checked the permissions on the containing directory? I think that ‘wx’ permissions allows deleting files within the directory. Thanks. A slight variation on your suggestion, I re-ran the test but with x as directory (rather than file) - same problem: docker exec -u 99 -it EmbyServer sh / $ mkdir /media/TV/x / $ chmod go-wx /media/TV/x / $ ls -l /media/TV/ | grep 'x' drwxr--r-- 1 99 root 0 Jan 11 12:09 x So directory x should only be writable by nobody Let's see if that's true: docker exec -u 1006 -it sonarr sh $ whoami abc $ grep abc /etc/passwd abc:x:1006:100::/config:/bin/false $ ls -l /tv/ | grep x drwxr--r-- 1 99 root 0 Jan 11 07:09 x $ echo 'dodeedododeedo' > /tv/x/file.txt $ ls -l /tv/x/file.txt -rw-r--r-- 1 abc users 15 Jan 11 07:17 /tv/x/file.txt $ Nope! Edited January 11, 2021 by CS01-HS Quote Link to comment
CS01-HS Posted January 11, 2021 Author Share Posted January 11, 2021 This is worse than I thought. I created a directory in the unraid console owned by root and not readable, writable or executable by anyone else: mkdir /mnt/user/Download/TV/y chmod go-wxr /mnt/user/Download/TV/y drwx------ 1 root root 20 Jan 11 18:49 y/ And apparently any user in my sonarr container (not set as privileged) can write to and delete from it freely. This can't be intended behavior, can it? Quote Link to comment
ken-ji Posted January 20, 2021 Share Posted January 20, 2021 Looks like a bug with the shfs used by Unraid. Quote Link to comment
CS01-HS Posted January 21, 2021 Author Share Posted January 21, 2021 On 1/20/2021 at 10:31 AM, ken-ji said: Looks like a bug with the shfs used by Unraid. Based on your own testing or what I reported? Every container with root access seems like a significant security risk. I thought this would get more interest. Am I misunderstanding? Quote Link to comment
ken-ji Posted January 21, 2021 Share Posted January 21, 2021 I did some tests and filed a bug report. But seems like no one has responded so far. 1 Quote Link to comment
CS01-HS Posted March 27, 2021 Author Share Posted March 27, 2021 UPDATE: I applied the fix described in @limetech's linked comment - problem solved. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.