Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ksmbd: not respecting sticky bit permission on shared directory #610

Open
riobard opened this issue Mar 14, 2024 · 2 comments
Open

ksmbd: not respecting sticky bit permission on shared directory #610

riobard opened this issue Mar 14, 2024 · 2 comments

Comments

@riobard
Copy link

riobard commented Mar 14, 2024

Sticky bit is used to implement shared directories:

The most common use of the sticky bit is on directories residing within filesystems for Unix-like operating systems. When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically, this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files. This feature was introduced in 4.3BSD in 1986, and today it is found in most modern Unix-like systems.

ksmbd does not correctly handle permissions with sticky bit. Steps to demonstrate on Alpine Linux 3.19.1 with Linux 6.6.21 kernel and ksmbd-tool version 3.5.1.

(Assuming there exist two users user1 and user2 whose primary group is share, and ksmbd.adduser correctly configured for both.)

# sudo mkdir -p /mnt/share
# cd /mnt/share
# sudo chgrp share .
# sudo chmod 1775 .
# sudo -u user1 touch file1.txt
# sudo -u user2 touch file2.txt

The above commands create a directory named share that is owned by root:share, and is group-writable. With the sticky bit set, files in share can be deleted only by its actual owner or root. Verify that the setting is correct

# sudo -u user1 rm file2.txt
rm: can't remove 'file2.txt': Operation not permitted
# sudo -u user2 rm file1.txt
rm: can't remove 'file1.txt': Operation not permitted

/etc/ksmbd/ksmbd.conf config:

[test]
path = /mnt/share
write list = @share

Connect to test over SMB as user1, and you can delete both .txt files.

Expected behavior: deny deletion of file2.txt due to permission violation.

@namjaejeon
Copy link
Member

Okay, there is no problem against samba. only ksmbd issue. right ?

@riobard
Copy link
Author

riobard commented Mar 17, 2024

@namjaejeon Yes, samba handles the sticky bit correctly, and only ksmbd exhibits the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants