Confusion about permissions

  • Hi,


    I am pretty unexperienced but am quite happy how I managed to set up my OMV.
    There is one thing I didn't quite get though.


    What is the purpose of the different ways (1,2,3) of giving permissions?


    1) When adding a share there is the section permissions with the default "Administrator: read/write, Users: read/write, Others: read-only"



    2) As soon as I added a share I can set priviliges:







    3) I also can set permissions via ACL:





    I just seems a bit redundant and tbh I don't really know if I am using it the right way.


    When adding a share I always select "Administrator: read/write, Users: read/write, Others: no access" because I don't want that "others" (whoever that might be :/ ) have access on this share. I don't feel this is necessary thought because it is not the default.


    Then I go to priviliges and select "Read/Wright" or "Read-only" for my user and "No access" for all the other users who should not have access.


    I never tough ACL because I don't really know what I need it for. I think it once had trouble with permissions for subfolders of a share and used ACL to recursively set permissions to all subfolders but that's about it.



    So I'm a bit lost and would appreciate any advice. Can anyone give me a quick overview or a hint in the right direction?


    Thanks in advance
    Eggsplorer

    • Offizieller Beitrag

    Maybe this -> link helps.
    _______________________________


    Edit:
    To try to clear up a bit of confusion - Owner, Group and Others permissions were native to Linux from the beginning. ACL's, where permissions are set by a specific user name or group name, are add-on's that are stored in a files extended attributes. Using ACL's are where users tend to get in trouble. ACL's do not mix well and, in many cases, conflict with standard permissions.


    Consider the following:


    The dialog boxes, above, are a little misleading. The red box is were ACL's are set. Don't use this or check boxes there.
    The green box (labeled extra options) is where standard permissions are set.

  • Thank you so much. This helped a lot indeed.


    I am kinda relieved to see that permissions are so complex that even experienced users aren't all that confident in using the different methods in OMV.
    I think I got a rough idea on how I have to use permissions for my intentions. Thanks you!

    • Offizieller Beitrag

    Just remember that any user you add to your OMV server, will be added to OMV's "users" group by default. And, if the user created in OMV is identical to the username and password (cap's and all) that you're using to login to your client, you'll get transparent access to shares from that client.

  • Just remember that any user you add to your OMV server, will be added to OMV's "users" group by default. And, if the user created in OMV is identical to the username and password (cap's and all) that you're using to login to your client, you'll get transparent access to shares from that client.


    Not sure if you're pointing this out as a warning, but yes this is bad if a system admin is unaware:


    EVERY USER you create in OMV gets added to the linux system level group called "users"


    #cat /etc/group | grep users:




    So if you are create shares with "Extra options" including any type of "read" access for members of group "users", then it appears they will be able to read those files. Very bad in our case, where we are trying to figure out how to use OMV with private shares whose access can only be gained by membership to a group called sharename_RO or sharename_RW depending on if user needs read-only or read-and-write access. Unsuccessful so far.

    • Offizieller Beitrag

    EVERY USER you create in OMV gets added to the linux system level group called "users"

    True. But that doesn't mean that admin's have to leave the "users" group assigned to any shared folder. The selected group can be changed in the GUI. Further, any user can be removed from the users group, and added to other add-on group(s) of the admin's creation.


    There's flexibility in it. Setups can be as simple as using one group and one shared folder, or several of both.

  • True. But that doesn't mean that admin's have to leave the "users" group assigned to any shared folder. The selected group can be changed in the GUI. Further, any user can be removed from the users group, and added to other add-on group(s) of the admin's creation.
    There's flexibility in it. Setups can be as simple as using one group and one shared folder, or several of both.


    True, you could remove "users" as the owners group from the standard permissions, and change it to ..... hmm


    private_sharename_users


    Which would give everyone the max access you define (i.e. rwx) to that share at standard level


    then, you could have to OMV level groups like:


    GRP_private_sharename_RO
    GRP_private_sharename_RW


    and use Access Rights Management > Shared Folder > PRIVILEGES to map the corresponding RO and RW access to those groups.


    Woohoo. If that works, I think that's exactly how I'll do it.


    So everyone is still getting put in "users" but "users" would not be used for any of our shares.


    Thanks!

    • Offizieller Beitrag

    I looked a privileges in times past, but it seemed to be irrelevant to file and folder access so I didn't pursue it .


    *** Of course there is a limitation of I think 16 chars max for groupname in debian to consider.


    Also I think a user can only be a member of 16 groups? That's a problem.

    Back in the day, I worked with giant AD domains, several nested groups, lots of users etc. Frankly, looking back, much of the complexity was needless. It could have been streamlined and simplified.


    Since I'm using OMV on a small scale, I never noticed limitations because I've never had the need to cross the suggested lines. The +16 character group name limitation appears to be true, but I have no practical means of testing a single user, in +16 actual groups, attached to +16 individual shares.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!