• [6.8.3] [6.9.0] [6.9.1] shfs seems to ignore permissions


    ken-ji
    • Solved Urgent

    create a test directory in /mnt/user/Downloads

    root@MediaStore:/mnt/user/Downloads# ls -al test
    total 0
    drwx------ 1 root   root       0 Jan 20 23:33 ./
    drwxrws--- 1 nobody users 205274 Jan 20 23:33 ../
    root@MediaStore:/mnt/user/Downloads# ls -ld /mnt/{cache,user}/Downloads
    drwxrws--- 1 nobody users 205274 Jan 20 23:33 /mnt/cache/Downloads/
    drwxrws--- 1 nobody users 205274 Jan 20 23:33 /mnt/user/Downloads/

     

    when this directory is mounted in a container like so

    root@MediaStore:~# docker run --rm --name box -d -v /mnt/cache/Downloads:/media alpine sleep 3600
    131ed3b6357ba8253513afc5e536361adf39de6ac5ca26ccdf22337770d60c76
    root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file'
    uid=1002 gid=0(root)
    drwxrws---    1 99       users       205274 Jan 20 15:33 /media
    touch: /media/a_file: Permission denied
    root@MediaStore:~# docker stop box
    box
    root@MediaStore:~# docker run --rm --name box -d -v /mnt/user/Downloads:/media alpine sleep 3600
    0dc76c0b4c8c6cf3f7b05c998a96e96a18e6f394e0e0bada60b66db3225c17c8
    root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file'
    uid=1002 gid=0(root)
    drwxrws---    1 99       users       205274 Jan 20 15:33 /media
    -rw-r--r--    1 1002     root             0 Jan 20 15:40 /media/a_file
    root@MediaStore:~# docker stop box
    box

     

    Seems like when the path is mounted via the user share path, the file permissions can be ignored in a specific situation

     

    Edit:

    It seems to be shfs itself - since the following issue occurs at the Unraid level

    root@MediaStore:/mnt/user/Downloads# echo x > a
    root@MediaStore:/mnt/user/Downloads# chmod 600 a
    root@MediaStore:/mnt/user/Downloads# ls -l a
    -rw------- 1 root root 2 Mar 23 21:44 a
    root@MediaStore:/mnt/user/Downloads# ls -l /mnt/cache/Downloads/a
    -rw------- 1 root root 2 Mar 23 21:44 /mnt/cache/Downloads/a
    root@MediaStore:/mnt/user/Downloads# cat a
    x
    root@MediaStore:/mnt/user/Downloads# su nobody -s /bin/sh
    nobody@MediaStore:/mnt/user/Downloads$ cat a
    x
    nobody@MediaStore:/mnt/user/Downloads$ cat /mnt/cache/Downloads/a
    cat: /mnt/cache/Downloads/a: Permission denied
    nobody@MediaStore:/mnt/user/Downloads$ echo y > a
    nobody@MediaStore:/mnt/user/Downloads$ cat a
    y

     

    mediastore-diagnostics-20210120-2344.zip

    • Like 1
    • Thanks 1



    User Feedback

    Recommended Comments

    I just retested with 6.9.0 and the same issue still exists

    root@MediaStore:~# docker run --rm --name box -d -v /mnt/cache/Downloads:/media alpine sleep 3600
    520f6d86f848a8558c1ac66f01107f0c02b63bad8481af71491aee5523000b0b
    root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file'
    uid=1002 gid=0(root)
    drwxrws---    1 99       users       245858 Mar  7 23:56 /media
    touch: /media/a_file: Permission denied
    root@MediaStore:~# docker stop box
    box
    root@MediaStore:~# docker run --rm --name box -d -v /mnt/user/Downloads:/media alpine sleep 3600
    4c5815e3e8d5b43c0d6b667dcf88cea7eb2d6b842a67125c606660c0613d22fe
    root@MediaStore:~# docker exec -u 1002 -it box sh -c 'id; ls -ld /media; touch /media/a_file && ls -l /media/a_file && rm -v /media/a_file'
    uid=1002 gid=0(root)
    drwxrws---    1 99       users       245858 Mar  8 14:03 /media
    -rw-r--r--    1 1002     root             0 Mar  8 14:04 /media/a_file
    removed '/media/a_file'

     

    • Like 1
    Link to comment
    ken-ji

    Posted (edited)

    @limetech

    Seems like a bug with shfs itself:

    root@MediaStore:/mnt/user/Downloads# echo x > a
    root@MediaStore:/mnt/user/Downloads# chmod 600 a
    root@MediaStore:/mnt/user/Downloads# ls -l a
    -rw------- 1 root root 2 Mar 23 21:44 a
    root@MediaStore:/mnt/user/Downloads# ls -l /mnt/cache/Downloads/a
    -rw------- 1 root root 2 Mar 23 21:44 /mnt/cache/Downloads/a
    root@MediaStore:/mnt/user/Downloads# cat a
    x
    root@MediaStore:/mnt/user/Downloads# su nobody -s /bin/sh
    nobody@MediaStore:/mnt/user/Downloads$ cat a
    x
    nobody@MediaStore:/mnt/user/Downloads$ cat /mnt/cache/Downloads/a
    cat: /mnt/cache/Downloads/a: Permission denied
    nobody@MediaStore:/mnt/user/Downloads$ echo y > a
    nobody@MediaStore:/mnt/user/Downloads$ cat a
    y

     

    I hope this is not directly caused by Limetech's stance that Unraid is an appliance and should only have the root user.

    As this can cause breakage with NFS shares, ransomware protection and general stuff and use cases that expect file permissions to protect stuff

    Edited by ken-ji
    • Like 1
    • Thanks 1
    Link to comment

    Very interesting.  To fix, open a Terminal window and type:

    echo 'shfsExtra="-o default_permissions"' > /boot/config/extra.cfg

    Then you must Stop/Start array.  Also this will persist across reboots, hence to undo you must delete the file.

     

    This is a mount option that tells FUSE to let the kernel handle file system permissions.  This used to be how FUSE worked by default and somewhere along the line it got changed, probably in transition from FUSE v2 to v3.  This bug will get fixed in Unraid OS 6.10 where we can have a little beta testing before wider deployment.

     

     

    • Like 1
    Link to comment


    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.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.