Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Samba Sticky Bit Permissions with Windows

  1. #1
    Join Date
    Aug 2011
    Beans
    29

    Samba Sticky Bit Permissions with Windows

    Hello all!

    I have a question I was wondering you all could answer for me. It deals with the sticky bit with Ubuntu 12.04 LTS, Samba, and a Windows client environment.

    I have an Ubuntu 12.04 LTS server acting as a PDC and file server on a Windows client environment, mainly Windows XP Pro.
    There's a particular share that I need to have users be able to read, write, and modify files, but CANNOT delete them.

    I've read up both on these forums and others through Google searches that setting the stick bit on the folder containing the files would remedy this; that if I did that then only the owner of the file can delete it.

    However, when testing this, the user can still delete the file. This is what I have specifically:

    On the Linux level, I have the SUID, SGID, and sticky bit set on the folder, in this case called 'forms.' I did this so whenever a file is put in there, it sets the user to the folder owner (root) so the sticky bit would take affect (since the user isn't root), and the group is set to the folder's group, so that the users belonging to that group can still read and write to that folder.

    On the Samba level, I have valid users set to the group that owns the folder, read only set to no so they can write to it, create mask to 0660, and directory mask to 0770, and guest is set to no.

    When I have a regular user set a file in the share, it properly sets the group and owner correctly, but if he then tries to delete the file, he can. If I understand all this correctly though, he shouldn't be able to.

    So...what am I doing wrong exactly? *confused*

  2. #2
    Join Date
    Jul 2008
    Beans
    Hidden!
    Distro
    Ubuntu 14.04 Trusty Tahr

    Re: Samba Sticky Bit Permissions with Windows

    Quote Originally Posted by Methus View Post
    Hello all!

    I have a question I was wondering you all could answer for me. It deals with the sticky bit with Ubuntu 12.04 LTS, Samba, and a Windows client environment.

    I have an Ubuntu 12.04 LTS server acting as a PDC and file server on a Windows client environment, mainly Windows XP Pro.
    There's a particular share that I need to have users be able to read, write, and modify files, but CANNOT delete them.

    I've read up both on these forums and others through Google searches that setting the stick bit on the folder containing the files would remedy this; that if I did that then only the owner of the file can delete it.

    However, when testing this, the user can still delete the file. This is what I have specifically:

    On the Linux level, I have the SUID, SGID, and sticky bit set on the folder, in this case called 'forms.' I did this so whenever a file is put in there, it sets the user to the folder owner (root) so the sticky bit would take affect (since the user isn't root), and the group is set to the folder's group, so that the users belonging to that group can still read and write to that folder.

    On the Samba level, I have valid users set to the group that owns the folder, read only set to no so they can write to it, create mask to 0660, and directory mask to 0770, and guest is set to no.

    When I have a regular user set a file in the share, it properly sets the group and owner correctly, but if he then tries to delete the file, he can. If I understand all this correctly though, he shouldn't be able to.

    So...what am I doing wrong exactly? *confused*
    The sticky bit only works if the user is NOT in the group and is NOT the owner of the file. The best example of this is the /tmp directory. it's set up exactly like you want. A user who is NOT the owner or in the group can't delete that file.

    Linux permissions are just that permissions. There is no other "ownership" rights. As the group rights are NOT inherited unless you specifically set that by SGID or SUID you can't use the sticky bit. File permissions are slightly different from directory (folder) permissions. The permissions rw are the same but the eXecute permissions mean different things x for files means a executable script or binary file. A directory uses the X as meaning you can transit (descend into) that directory.

  3. #3
    Join Date
    Aug 2011
    Beans
    29

    Re: Samba Sticky Bit Permissions with Windows

    So, in essence, there isn't a way to have a directory where a group can share files, but be denied the privilege to delete them if they're not the owner/creator of said file? And that's because they are in the same group?

    It just seems to me that this would be a feature many others would want. Or am I out in the cold on this one?

    Would it work if the group was set differently (to one they are not in), but the permissions were set where everyone can read/write to the files?

  4. #4
    Join Date
    Sep 2011
    Beans
    1,531

    Re: Samba Sticky Bit Permissions with Windows

    You can choose to allow a user to read a file but not write to it.

    But if they have permission to write to the file then they would also by default be able to delete it. Think about it- someone could open a word document, delete all the text, then save the empty word document thus effectively deleting it.

  5. #5
    Join Date
    Aug 2011
    Beans
    29

    Re: Samba Sticky Bit Permissions with Windows

    Yes, but the file itself would still be linked; it'd just be an empty file, but the file itself would still exist. I'm trying to find a way to keep non-owners of the file from unlinking it.

  6. #6
    Join Date
    Jul 2008
    Beans
    Hidden!
    Distro
    Ubuntu 14.04 Trusty Tahr

    Re: Samba Sticky Bit Permissions with Windows

    Quote Originally Posted by Methus View Post
    Yes, but the file itself would still be linked; it'd just be an empty file, but the file itself would still exist. I'm trying to find a way to keep non-owners of the file from unlinking it.
    What is a "non-owner"? All file are created with 3 types of users and 3 levels of permissions. These are Linux permissions, not Samba permissions. Samba permissions will not override Linux permissions. You can provide exceptions to Samba permissions these but you have to live with Linux rules ultimately.

    You also can create exceptions to the basic Linux permissions, but they are best use as exceptions and not the rules. These are Linux file ACL's and file attributes. The file attributes are set with chattr. If a file's attribute is set to immutable it can't be removed unless the attribute is changed first.

    The concept of "ownership" is not really accurate for Linux files and directories. The user (owner) is the creator, but if you set permissions to rw for both the the owner and the group, both entities have the same permissions to act on that file. If you were to add rw as the permissions then all users (the rest of the world) would have the same permissions.

    I control my user access by the group permission settings. I only think of the owner as the user that created the file. For my shared files I set the root directory of the share with 2775 permissions. Then I set the group to one that holds all the users that need access to the share. From then on all files have permissions of 664 and all directories have permissions of 775.

    It might be helpful to deal with a specific set of circumstances (your actual problem) to push this forward. The tools are there to achieve what you want but they may not be what you might think.
    Last edited by redmk2; December 17th, 2012 at 04:22 AM.

  7. #7
    Join Date
    Aug 2011
    Beans
    29

    Re: Samba Sticky Bit Permissions with Windows

    Okay, this is my scenario...

    I administer an Ubuntu 12.04 LTS server for a local police station. This network is setup on a Samba domain with roaming profiles and file shares. A particular file share contains database files for a records management system program that is installed on all of the client computers (Windows XP Pro). Everytime a user logs in, this particular share is mapped to a network drive based on the fact that they are in the group that has access to that share.

    I have it, in Linux, where the directory containing these files are set as rw for the group, so any user logging in to a client machine can open these files with the program and add information to it. However, if for any reason in the future an employee becomes disgruntled, I don't want them to be able to go into the share and delete all of the database files.

    In short, I need the directory open to group for rw access for this program, but I do NOT want them to be able to outright delete (unlink?) the files in the share.

  8. #8
    Join Date
    Jul 2008
    Beans
    Hidden!
    Distro
    Ubuntu 14.04 Trusty Tahr

    Re: Samba Sticky Bit Permissions with Windows

    Quote Originally Posted by Methus View Post
    Okay, this is my scenario...

    I administer an Ubuntu 12.04 LTS server for a local police station. This network is setup on a Samba domain with roaming profiles and file shares. A particular file share contains database files for a records management system program that is installed on all of the client computers (Windows XP Pro). Everytime a user logs in, this particular share is mapped to a network drive based on the fact that they are in the group that has access to that share.

    I have it, in Linux, where the directory containing these files are set as rw for the group, so any user logging in to a client machine can open these files with the program and add information to it. However, if for any reason in the future an employee becomes disgruntled, I don't want them to be able to go into the share and delete all of the database files.

    In short, I need the directory open to group for rw access for this program, but I do NOT want them to be able to outright delete (unlink?) the files in the share.
    How do you create inheritance of the group in sub-directories and files; or do you at this time? Why can't you just delete the user if you demote or terminate them? You do run backups on the data; right? Do you have many files like this? Do you know how hard links (not soft links) work? How many users are in the group?

  9. #9
    Join Date
    Aug 2011
    Beans
    29

    Re: Samba Sticky Bit Permissions with Windows

    How do you create inheritance of the group in sub-directories and files; or do you at this time?
    I have it set in Samba to force the user to root and the group to the appropriate group for all files within the share directory.

    Why can't you just delete the user if you demote or terminate them?
    A disgruntled employee could be caused by numerous things: demotion, cut of paycheck or hours, write-up, an argument, etc. In these occurrences the employee still needs access to the file share and the database for his job.

    You do run backups on the data; right?
    Every morning at 0300 when the database files are less likely to be locked from use.

    Do you have many files like this?
    There's about 110 files in this particular share that needs to be protected.

    Do you know how hard links (not soft links) work?
    Originally I did not, but I just did some skimming and light reading on it. From what I understand, a soft link acts like a redirect to the original filename, which points to the inode with the data.
    A hard link acts as another filename that points to the inode itself.

    How many users are in the group?
    This is a small department, so there are currently only 9 users.

  10. #10
    Join Date
    Jul 2008
    Beans
    Hidden!
    Distro
    Ubuntu 14.04 Trusty Tahr

    Re: Samba Sticky Bit Permissions with Windows

    Quote Originally Posted by Methus View Post
    I have it set in Samba to force the user to root and the group to the appropriate group for all files within the share directory.
    There are much better ways of doing this. In fact when you do this you loose the use of group called "others". It's much better to set this up in the linux file system (ext4?)

    A disgruntled employee could be caused by numerous things: demotion, cut of paycheck or hours, write-up, an argument, etc. In these occurrences the employee still needs access to the file share and the database for his job.
    I won't comment on the social aspects of employees, other than you have to have some faith in there integrity,

    Every morning at 0300 when the database files are less likely to be locked from use.
    You could easily back the data up hourly with rsnapshot.

    There's about 110 files in this particular share that needs to be protected.
    If these files are all hardlinked to another subdirectoy that only a few had access to then the files could not be deleted until BOTH links to the inode are removed. In other words deleting the link in the shared directory WOULD NOT delete the file.

    Originally I did not, but I just did some skimming and light reading on it. From what I understand, a soft link acts like a redirect to the original filename, which points to the inode with the data.
    A hard link acts as another filename that points to the inode itself.
    Allowing you to protect yourself.


    This is a small department, so there are currently only 9 users.
    Are you creating new files on a daily basis?

    Here are some ideas of things you can do. Create a group that has rw rights in the share. Set the GID bit on the root directory (chmod 2775) and use chgrp to change the group to this group (you can use sambashare or create your own. I created a group named smbusers. This means you can get rid of the force commands in you share definition.

    At this point if your users become untrustworthy you can remove them from the group and the will have no access to the share.

    If you like, you can hard link all of the files to another directory that has only root access (you so have root access I assume). I this way only you can finally delete the files. FYI (hard links take up no real extra space as there is only one file with 2 links.

    The biggest problem is the need to have RW without the ability to delete a file. You will never be able to this as RW includes the right to delete. The only other option is to look at ACL's. I don't use ACL's because each one is individual and it becomes a mess to administrate them. But as you have only 9 users...

    So in short you can use SGID and group inheritance along with hard links and or ACL"s

    If you want to do this I would create a test share so you can see every step of the way what happens. As always YMMV.
    Last edited by redmk2; December 17th, 2012 at 05:58 AM.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •