What is the difference between Privileges and ACL?

  • I find this very confusing.

    I want to set up users that bellong to groups.
    I want to have 50 or so shares, each share should have 1 user or 1 or more groups allowed to axs it.
    I want to use cifs.
    File system is ext4.
    Users use MAC, Linux, Windows Xp, Windows 7, and Windows 8.

    Can I set security via "Privileges" only? If so, what is the purpose of ACL?
    Or am I supposed to set both?

    In fact, it is even more confusing than that.

    When I create a share in OMV I am presented by the GUI with a permission opion as such:
    "Administrator: read/write, Users: no access, Others: no access"

    What exaclty is this for? What should I set it to?

    I ask this becuase later I need to set the permissions in 2 other places
    (1) Privileges button
    (2) ACL button

    So that is a total of 3 places...

    For example, let's say I create a share as such
    "Administrator: read/write, Users: no access, Others: no access"

    Then later I press the Privilages button and give my custom group (Accountants)
    read/write privilleges.

    John belongs to Accountants group and I think all users belong to users group...
    So let's think about this...

    Do these Accountants have read/write axs to the share or not?? Conflicting settings to say the least.
    In one place I have Users: no access, in the other place I have Accountants: read/write

    Let's consider scenario two:
    I create a share as such
    "Administrator: read/write, Users: read/write, Others: no access"

    Now I press the Privileges button because I only want Accoutants (once again) to have axs.
    I give them read/write privvileges.

    But what is the state of things? Again it is clear as mud. Why would accountants have the only axs? When I made the share I said all users have read/write.

    Very confusing.

    Then there is the whole question of what is the ACL button for when you have a privileges button.

  • Knowledge about Linux file system permissions is something that any Linux system administrator should have. OMV only uses what any Linux distro offers and the result is the setting of ACL's and privileges for shares.
    I believe that explaining these file system permissions is beyond the scope of this forum. To get an idea how these permissions work I recommend to read an article like THIS ONE.

    Homebox: Bitfenix Prodigy Case, ASUS E45M1-I DELUXE ITX, 8GB RAM, 5x 4TB HGST Raid-5 Data, 1x 320GB 2,5" WD Bootdrive via eSATA from the backside
    Companybox 1: Standard Midi-Tower, Intel S3420 MoBo, Xeon 3450 CPU, 16GB RAM, 5x 2TB Seagate Data, 1x 80GB Samsung Bootdrive - testing for iSCSI to ESXi-Hosts
    Companybox 2: 19" Rackservercase 4HE, Intel S975XBX2 MoBo, C2D@2200MHz, 8GB RAM, HP P212 Raidcontroller, 4x 1TB WD Raid-0 Data, 80GB Samsung Bootdrive, Intel 1000Pro DualPort (Bonded in a VLAN) - Temp-NFS-storage for ESXi-Hosts

  • Well, datadigger, you see it is kinda confusing for people without linux knowledge and I have to say, I still cannot tell 100% for what to use ACLs and for what to use privilieges.

    I checked it recently with the forum user Dennis and my asumptions how it should be/work wasn't always correct. Also some users told on the forums that using Priviliges with groups doesn't work correctly because you STILL have to enable the rights for the individual users - which are in the group - because the users get written to the "Not allowed" part of the smb.conf and don't get removed there by just adding priviliges for the group.

    So either way, for one side we should have a better explanation, for the other side we may have to check that behaviour (I did not check, but I now may check it later).


    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"

    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

    I host parts of the omv-extras.org Repository, the OpenMediaVault Live Demo and the pre-built PXE Images. If you want you can take part and help covering the costs by having a look at my profile page.

  • Quote from "datadigger"

    Knowledge about Linux file system permissions is something that any Linux system administrator should have. (...)

    Thank you for this helpful post! I'm really exited about it! :twisted: :roll:
    Really great, that you send us to a commandline, when we've a GUI. :o
    Did you know that there are at least three (!!) kind of permissions avaiable in OMV?

    1st: Folder-Rights - mostly clear.
    2nd: Permissions: Maybe the same, but only for users. But I'm not shure, because I haven't had time to get into it.
    3rd: ACL. That tiny little thing, that you might want to mix-up with permissions. But it's not the same, Dude. ACL are more than file-and-folder-permissions. As a "Linux system administrator" you should maybe want so see this man-pages: http://www.bestbits.at/acl/man/man.html

    So - I'm confused and explanation would be great. :)

  • Learning permissions, privileges, ACL's and other access methods may be easy for some hard for others. I've read, watched videos, played with and still feel I barely understand basic linux permissions, from file, directory, user, group, and how each interacts.

    I feel it is like a child learning to walk. As children we watched our family and most everyone do it, we fell on our butts many times, we never gave up and learned how it was done. The key is we never gave up. So we just have to keep trying and never give up.

    Building a GUI to do what is done at the CLI can be tricky. And once the GUI is done it still may not do what the user expects or was looking for.

    An off the wall example. Think of the GUI as a home and the CLI as the local big building supply store. I can use any of the pieces from the building supply to build my home. (CLI to build GUI) And when I'm done building I have my house (the GUI). But oh, now I want to add a deck, back to the building supply (the CLI), and build some more and make changes to the house (the GUI). Or I could build the deck (the CLI) next to the house and not make changes to it (let GUI alone). So the goal is to satisfy as many as possible and allow others to make custom changes as they need. Though doing custom work may not be easy or even possible.

    I keep reading and playing to learn more.

    So I believe Volker has done a very good job building a very usable and reliable NAS for many users.

  • I love privileges but it is damn hard to explain. But I will try..... some.

    Ok, when you setup a shared folder you have a drop down box. This box is so important because it effects who will be allowed to access the folder later.

    Administrator: read/write, Users: read/write, Others: no access (this is chmod 770) Good if you only want root, owner and users created on omv to access files.
    Administrator: read/write, Users: read/write, Others: read-only (this is chmod 775) Good for media folders because plex user would be an alll others user

    The first part is The owner (administrator), the 2nd is the group (in omv the main group is users) and the 3rd part is all others.
    This is setting the permissions for the shared folder and in with privileges you see a number like 755. You can used the command chmod to set permissions on a folder or file. The first number 7 is the owner perms, the second number 5 is the group perms, and the 3rd number 5 is all others.
    The number for each means
    7= owner ( can read/write, execute) (default owner is "root" in omv shared folder creation)
    5=group (can read and execute) (default "aka primary" group is "users" in omv shared folder creation)
    5=all others (can read and execute)

    Here is a chmod calculator. It should help you in figuring out how the numbers are derived.

    7= read, write, exectute
    6= read, write
    5= read, execute (I believe in omv shared folder creation "Others: read-only" is given a 5 in chmod and not a 4. So really a read+execute)
    4= read-only
    etc.. play with the calculator and you will get the idea.

    Now I will give you an example to help you some in understanding. We want to create a media folder.
    owner= read, write,execute
    users (the main group used in omv)= read, write, execute
    all others (any user or group) = read-only
    After looking at this we know we need chmod 775 so we choose this from the drop down menu when we create the shared folder:
    Administrator: read/write, Users: read/write, Others: read-only
    This will create a shared folder with the primary group "users". Any user created in OMV web-gui is automatically part of the "users" group.
    Now you share the folder with SAMBA. Any user that you created can connect from their machine and put on files via their files on the shared folder because they are part of the users group and users group has a chmod value 7 (read, write, execute).
    So the user creates a folder, puts in some movies, etc...
    Here is the part a lot of people don't get. Now we want the plex user for plex media server to be able to read the files. The plex user belongs to no group. It was created on install of plex media server. So it belongs to the all other category, or the 3rd value in the chmod number. Which here is a 5 which is read-only.
    The plex user will be allowed read-only access to the folder even though it is not an owner(of the directory or files) or part of the group users. The plex user will be able to read the files and that is all it needs. No ACL.
    Privileges are permissions that are written to the filesystem and chmod is the command you use to change those permissions. Normally the root user is used to change permissions with chmod.
    To change perms on a file:
    chmod 775 file1
    To change perms on a folder recursively( recursive means all files and folders below, or in, the folder being chmodded):
    chomd -R 775 media

    chmod is to change the filesystem permissions. chown is to change ownership.
    When you use this command "ls -la" you can see a files perms, owner and primary group,
    Here is an exmample:

    drwxr-xr-x 3 vbox vboxusers 4096 Jul 31 2012 vbox

    'Here you have another format to show you permissions
    The first thing there is a d. This tells you that this is a folder ( a hyphen, - , would mean it is a file)
    Then you have three sets of perms (owner, group, others)
    r= read
    -=means the owner, group or others does not have that permission.
    Then you have vbox (owner), vboxusers (primary group)
    To change ownership of a file:
    chown user1:users file1
    To change ownership of a folder recursively:
    chown -R user1:users folder1 (user1 could be user name in omv and users is the primary group for users in omv)

    ACL is like a program running over the filesystem that can control access to the filesystem. If someone wants to explain that feel free. I will try to answer questions on privileges.

    Hopes this helps some of you.... :roll: I don't use ACL at all because I don't need it.

    PS- stat is a good command to check perms on a file or folder.
    stat file1
    stat folder1

  • tekkbebe,

    Thanks for your description. It helps and I am learning, and I really do like how permissions can be used. Just learning it is like four blind guys trying to describe an elephant.

  • Ok, so we cleared up (thanks to tekkbebe) that the 1st permission setting upon a new share creation in omv is the unix file system permissions.
    That much most of us more or less guessed.

    Here are some targeted questions by category to clear up some key issues.
    I will mark each question with an id as such.. Q1, Q2, Q3, etc...

    OMV Unix Permissions

    These are set at omv share creation by web ui.

    Two common settings for omv are:
    Administrator: read/write, Users: read/write, Others: no access (this is chmod 770)
    Administrator: read/write, Users: read/write, Others: read-only (this is chmod 775)

    (Q1) Users is not specifically the omv unix group called "users", correct?
    "Users" is a concept not a specific group, right? It just happens that all users created in unix that are not root fall under the "Users" concept umbrella and since you made a custom omv unix file system group called "users" that too falls under the Users concept category. No?

    (Q2) Unix file sys perms are set as such
    all others

    So a key thing here for me is that there is only one group here. It is group, not groups. So which group does group refer to? Accountants or Engineers? You obviously can't specify this here, you can only assign a level of axs.
    In a system with many groups... how is the reference made to the target group? I think this is the main point of confussion with regards to unix file sys perms.

    (Q3) You say, "(default "aka primary" group is "users" in omv shared folder creation)".
    What does this mean? Was something done in omv to set the group reference to always mean "users"?
    If so how was this done?

    (Q4) I take it that if I create a user that does not belong to the users group, no matter what I do with Permissions button or ACL button later, he will not have axs because he is locked out at unix file sys level. Correct?

    OMV Permissions button

    (Q5) Is it the case that one should set the unix file system perms with high privs and then set the real axs privs via the Privileges button later?
    For example, If I want Accounts to have read/write axs to some share:

    I create a share as such
    Administrator: read/write, Users: read/write, Others: no access (this is chmod 770)

    I create a bunch of accountant users and add them to Accounting group.

    Then I click the Privileges button and give Accountants read/write, and then for all other groups in list I select no access?
    Of course, I also give me read/write axs so I can see any share.

    My point is that I was unable upon initial share creation to control which groups have what rights.
    The owner/group/users unix file sys perm scheme does not allow you to specify custom rights for each group....

    (Q5) Is the magic behind the Privileges button a custom omv axs list thing or is that also a unix file system permission thing?

    I'm guessing the following:
    The perms set with this button are used by omv to set a filter (axs list by name or group) for conditionally connecting users via network and are not at all related to unix file system perms.
    Once they are connected, they have file sys axs because all users created for axs list puroses by omv are also auto added to the unix file sys group "users".

    So when the share was made with Users: read/write.... then the connected person has read/write perms.
    If the share was made with Users: read.... then the connected person has read perms.
    This is where the picture isn't quite clear... because this doesn't explain why I can make a share with
    UNIX FILE SYS -> Administrator: read/write, Users: read/write, Others: no access (this is chmod 770)
    OMV PERMS -> Accountans: read/write, Management: read, Administrators: read/write, all othe rgroups: no axs

    In other words, once connected to the share, the actual permissions (read or read/write or no access) are not related to the original 3 octal unix file sys perms
    (UNIX FILE SYS -> Administrator: read/write, Users: read/write, Others: no access (this is chmod 770)) setting because each group has different rights.

    You see, all users bellong to "users" group. We set the 3 octal perms so that Users: read/write. Yet, we know that this is ignored because only users of the Accounts and Administrator groups have read/write!!

    So, if what this "Permissions button" also is something that sets some unix file sys perms, what does it do an how because it seems that it is not restricted to what that basic unix 3 octal (owner/group/other) scheme can do. Is this some additional layer on top or what?


    (Q6) Is the stuff behind what the Privileges button and the ACL button the same?
    What i mean is, do these two button provide a different view to the same thing or are these permission schemes different?
    If they are not the same, what is the purpose of each?

  • Q1 No, users is not a concept. It is an actual group created by OMV. Volker could have used any name but he decided on the group name as "users". In the drop down on shared folder creation he has Administrators, Users, and Others.
    Administrators=root (default owner)
    Users= users (primary group)
    Others= all others (all others is the normal terminiology)
    After a shared folder creation go into command line and run this command a level above the shared folder "ls -la".
    Notice the owner and group a look at perms. You could stat the folder too.

    Q2 No, a user can belong to many groups. But they always have a primary groups.

    Q3 When you create a folder or file it is usually assigned to a primary group. In OMV the group "users" is used so any user created is by default part of that group. If you make a folder Accountants and chown it say root:accountants (accountants being the group) you would have to add users to that group to be able to access the folder. Then any subfolders or files would have to have read/write access for the users to be able to access, so lets say chmod 770(give the user execute too). If you've put files and folders in the in the Accountants folder that are wrong perms you can do this to the folder to correct everything recursively:
    chmod -R 770 Accountants
    If there a files and folders in the Accountants folder that do not have the right ownership you can fix by:
    chown -R root:accountants Accountants (changes owner to root and group to Accountants)
    (these commands are run when you are 1 level above where the Accountants folder is locate. So if you are in Acconutants folder and you do a "cd .." command.
    To move back one level in a tree: cd ..
    To move inside a folder you see after running a list "ls" command: cd ./foldername (this way you don't have to write full path, there are other tricks too)

    Q4 the only acces a user with no group is dependent on how a folder is chmod. That is why it is very important you understand when you create a shared folder what privileges (for owner, group, & all others) you are giving access to the shared folder. After the shared folder is created you can modify the chmod of the folder in command line. If you did "cmod -R 777 foldername" then your no group user could read,write and execute.

    I will answer more later. Here is something you should think about. There is not just the filesystem we are dealing with to grant access. The share is being shared via Samba or AFP. There are other mechanisms in those services that control access to the shares. To get everything perfect all the stars have to align.
    Volker uses Samba or AFP to further contol/modify access. Samba is a beast to understand. I don't want to go there. You can not learn this all quickly.

    PS- I really believe in the use of webmin. It will get you behind the scenes, in the guts of a lot of this, and you can view, modify, etc.. stuff way faster. It helped me to understand linux way faster then if I had just used command line. It will also help you to understand uid and gid. You can look at various users and see what groups they belong to easily. Even using the file manager and moving around the filesystem easliy helped me get my footing.

  • An example of a user information in webmin. You can see primary group, groups the user belongs too. Notice primary is users. So this is an OMV user.
    Note that a user and group also has an id (UID, GID). Later as you learn more you will find that you can have id mismatches that can cause problems.

  • Q5- Once the basic filesystem perms are set. The shared folder is chmod 770, lets assume group is "users". Any user created in web-gui will have access to the folder according to the filesystem, because they are auto in the users gourp. If all folders and files in the shared folder are chmod 770 (and ownership is root:users) then any user(in users group) will be able to read/write to the shared folder. But now on top of the filesystem perms Volker uses SAMBA to further control access to the folders/files in the shared folder. If you look at your samba.conf you will see:

    valid users =
    invalid users =
    read list =
    write list =

    When you edit user access with the privileges button the users are being modified in these areas of the samba.conf. If the user is no access they will be on the invalid users list and be denied access to the share. You can figure out by making edits then looking at config what is going on... Does this help??

    Q6 They are not the same but both act to control file/folder access. Like I said before ACL is like another layer, extra attributes added to files and folders ( kinda like the rwx in privileges). If someone knows a good article on ACL please add a link to this thread. This really answers the primary question of this thread, without going into depth on ACL.

  • I think the picture is forming.

    Here is my take on it.

    The basic unix perms
    -users(owner) - usually should be the Admin (aka root) but in Linux default is the person who made it.
    -other(everyone with no user account on local computer)

    Is primitive legacy junk. The main problem with it...a problem that makes it useless in real life...is that you can only set perms for one group. Yes, you can add groups to that group... but the key point is that you can’t set custom perms per group for a given dir/file. All the groups you add to that group have the same axs to that share! So, you can add Accountants to the Engineers group... but then they have the same axs. You can't have custom axs for Accountants group and custom axs for Engineers group at the file system level with legacy Linux perms fo rthe same dir.

    Because of this extremely flawed perm design, Linux copied from Microsoft the ACL idea.

    Few people discuss Linux ACL perms, but since Linux kernel 2.6 Linux now supports ACL. ACL isn't just a layer on top of normal linux perms. You must mount the file system with ACL and if done so then ACL perms take precedence over legacy Linux perms (the owner-group-other scheme is ingnored). ACL in Linux is conceptually (from the usage/admin perspective) more or less a rip off from Microsoft ACL. It is a file system level feature so file system must support it. XFS for example auto uses ACL and you don't have to mout the file system in a secial way for ACL to be turned on. The kernel must also support it.

    With Linux ACL you can set custom perms for a list of groups or users for each dir. The key point is that this is the only way to set diff perms for Accountants group and diff perms for Engineering group at the file system level for the same dir.

    Now, I haven't researched SAMBA ACL like perms... but we are getting close to having a clear picture. I don't know if SAMABA just piggy backs off Linux ACL perms or if it uses its own non file system ACL scheme. My guess is that it implements its own based on the fact that it has its own axs list file. Also, because in the past Linux didn't even support ACL, it makes sense that SAMBA would have had to implement acl like axs features on its own.

    Tekkbebe, maybe you can confirm this.
    (1) When you make a new OMV share, the Administrator: read/write, Users: read/write, Others: no access setting is for the basic legacy Linux file system perms.
    (2) The Permissions button in OMV is for SAMBA perms which can be used instead of Linux file system ACL. This gives you the same end ressult except they are implemented and maintained by SAMBA and not the file system. This is what you sugested in your last post (unless I read it wrong). ofc ourse the end ressult is not exactly quite the same as Linux file system acl...but more on this later.
    (3) The ACL button in OMV is for Linux file system ACL permissions.

    In other words, I think that if you need ACL like functionality (ex. Accountants group read/write, Management group read-only, Me read/write) then you can do 1 of 3 things in OMV.
    (1) Set custom group perms with SAMBA using OMV Permissions button
    (2) Set custom group perms with Linux ACL using OMV ACL button
    (3) Set custom group perms with both SAMBA and Linux ACL using both OMV buttons (just make sure in this case that the settings match for both).

    The thing is..I use cifs(samba)... but what if someone uses NFS instead? Obviouslly pushing Permissions button isn't going to use SAMBA's acl like security features... which leaves 3 possibilities.
    (1) The OMV permissions button is only for SAMBA and does not work with other things like FTP,NFS, etc
    (2) The OMV permissions button does not use SAMBA security anything....and instead actually sets Linux file system ACL perms which can then be taken advantage of by FTP, SAMBA, NFS, etc because it is at the file system level and thus lower than the server software runing in user space. If this is the case, then perhaps the Permissions button is nothing more than a different view to what the ACL button gives but actually they both set the same thing (linux file system acl perms).
    (3) omv makes sure that each server soft (FTP,SAMBA,NFS) are the type of serv soft that each implement their own ACL scheme and when you use the OMV permissions button then OMV sets the perms in each server softwares own axs file (sets it in SAMBA's own axs file, sets in FTP applications own axs file, sets it in NFS servers own axs file, etc). I kind of doubt this is the case. I don't even think NFS has axs rules.

    Only you guys know how you implemented it.

  • @k...:

    "other" not someone without a local account but neither the user or in the group of the file/folder.

    And even if iam not tekkbebe, i can confirm your three points.

    Volker stated that permissions are used for the services, he did not said that there are any exceptions.


    PS: Only Volker knows how hes implemented it! He is the only active developer ...

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"

    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

    I host parts of the omv-extras.org Repository, the OpenMediaVault Live Demo and the pre-built PXE Images. If you want you can take part and help covering the costs by having a look at my profile page.

  • Quote from "davidh2k"

    "other" not someone without a local account but neither the user or in the group of the file/folder.

    David is right. Other is an account but just is not the owner or belong to the group in question.

    ACL was not part of linux originally and added to fix flaws in permissions design, just as you suggest. Perms, ACL, SELinux, Encryption are all security measures. In my mind layers of security.

    ***You mean "Privileges Button" above in many places. In SAMBA you have a simple authentication that can be used. When a user is created in the system there is a way to create an identical user in SAMBA ( same username and pass). There are many other methods for authentication (LDAP, MYSQL, AD, PAM, etc...) I'm sure the Privilege Button works with other services besides SAMBA. So Volker has setup the Privileges Button to properly configure any service that is in use (SMB/CIFS, AFP, NFS, etc..) The ACL Button is likely storing the information right in the filesystem.

    You have 3 sets of 1, 2, and 3...

    1st 1,2 3:
    1)What you are calling legacy perms.: Yes it is setting the standard rwx for owner, group, others.
    2) No, not just SAMBA. Explained in paragraph above. ***
    3) Yes

    Will finish later....

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!