Difference between setgid and ACL

J

JornZ

Hello all,

This has got me confused. I'm running a FreeBSD NAS and have some folders for which I need to give access to different processes such as transmission and sabnzbd. These run under different users and next to that I would like anything downloaded to be accessible by other users/process such as music player daemon as well. So I figured I could do this by creating a new group and making all needed users (at least the users these programs run under) members, make a folder and set ownership to a user from the earlier created group. Then I set the setgid bit and read/write access to all group members via chmod'ing with 2775.

This seems to work but now I'm also reading about ACL as well, do I need to do anything with this as well? I'm also accessing these files from a Windows PC by the way.

So to sum it up, I'm unsure of the difference between ACL and using the setgid bit to get what I want. Hopefully someone can shed some light on this for me :stud. Thanks for any replies, this has really got me confused.
 
I will try to answer this.

If something is setuid, when someone runs that file, that process will take on the privileges of the user account that owns the file (often root).
I believe (though not 100% sure) that setgid will assign the process permissions of the file's group.
A while back, I wrote a login manager that I enabled the s-bit on during installation so that any user could start it. Things like Wifi tools would probably do similar and the most obvious example is security/sudo which all users need to be able to run but if the conditions are met, their privileges need to be escalated which only root can do (thus s-bit is used).

ACLs are for specifying things like rwx on a file. They do not have anything to do with setting privileges once the file is run.
 
Thank you very much for answering. This already helps me, I think we're getting somewhere.

What I still don't understand after reading your post; the difference between ACL and setgid in what happens when trying to rwx the file by a member of the group. In the ACL case a group user does not take on the group permissions but access is granted through the permissions set for the group and in the setgid the user would get group permissions, but it already has those since it is in the group? So that last bit still confuses me. Maybe you can tell me where I'm missing something in my reasoning?
 
I think (and please someone correct me if I am wrong) but the setgid provides a broader way of doing something.

For example a file made by root has the following permissions user=rw group=r other=

Lets say I write a program that attempts to read that file. It will fail because my user is is not root. If I set the setuid flag of my program and chown it to the root user, it will now be able to read the file when I run it (since it has obtained root privileges).

However, my program only wants to read the file, it has no need to write to it, so for added safety I could keep the file chowned to root, but remove the sbit from the user=rwxs permissions and add it to the group permissions (so group=rxs) and also make sure the program is executable from people in the "other" group.

Now when my user runs the application, it will set my group to the group of the application file (probably wheel) and since the file I want to read has group=r, I can now read it without having full root permissions.

In other words, I am in the group kpedersen so for the file I want to read, I would come under the other group (which has no access). However, when I run my program, I inherit the wheel group for the duration which can read the desired file.
 
It's the other way really, chmod(1) and the likes provide only a subset of what ACLs can do. However with ACLs replicating the chmod g+s functionality for a directory is a bit tricky because you have to say in your ACL for the directory that all newly created items in that directory inherit the ACL of the parent directory.
 
I really appreciate the responses.

I also found this on wikipedia (lol):

Setting the setgid permission on a directory (chmod g+s) causes new files and subdirectories created within it to inherit its group ID, rather than the primary group ID of the user who created the file (the owner ID is never affected, only the group ID). Newly created subdirectories inherit the setgid bit. Thus, this enables a shared workspace for a group without the inconvenience of requiring group members to explicitly change their current group before creating new files or directories. Note that setting the setgid permission on a directory only affects the group ID of new files and subdirectories created after the setgid bit is set, and is not applied to existing entities.
Click to expand...

So for me the setgid seems the way to go. I need different programs (that run under their own user) to be able to access the files in the directory, which is possible if I collect these users in the same group.

To be honest I'm still not 100% sure on the difference between setgid and ACL for this specific case but I suppose you could choose to not set the setgid bit on a directory and have group access set for new files through ACL and have the same functionality.
 
You must log in or register to reply here.
Back
Top