Managing user rights

  • Hello everyone,


    after setting up my Raspberry Pi running the latest version of OMV I followed the tutorial on how to create a "samba" share for use with Windows.
    So far so good. I can create shared folders that are open to everyone on my network. How do I go about creating a shared folder that requires credentials of some sort (username+password?) to be used. I have some files that I would like to store on my NAS that shouldn't be available (not even with read only permission) to general users in my network.
    I hope that I have stated my problem clearly enough and I hope that you can help me.


    Thanks
    Robert

    • Offizieller Beitrag

    In the unlikely event that something goes severely wrong, have you backed up your SD-Card?
    ________________________________________________________________________


    (Note that this is not the most secure way to setup - however.)


    If all of the users, on your network, log into their PC's with unique User names and passwords:


    Under Access Rights Management, Users, you'd need to set up the same exact user names on OMV, with the exact same passwords, as they are set on the Windows PC's. (Note: Linux is sensitive to the capitalization of user names and passwords. They must be an exact match, Cap's and all, to the Windows user name and password.) This sets the stage to allow users to access OMV shares, automatically, using their Windows credentials.
    __________________________________________________________________________


    All users entered during the above process will be, automatically, added to OMV's "users" group.


    In Access Rights Management, Shared folders, click on a share and the ACL button.
    (Ignore the top window - those are extended permissions that can cause access conflicts to the Linux basic "Owner" "Group" and "Others" permissions settings in the bottom pane.)


    In the bottom pane, you can set Owner to root, and Group to users. (These are likely to be already set.) Finally, Others is changed to read only or none. (BTW: Read only is a reasonable option for media shares) Set the Replace and Recursive options to Green (or on), and Apply.
    __________________________________________________________________________


    Finally, you'd need to set options on the SMB share, layered onto the Shared Folder above.
    Go to Services, SMB/CIF, in the Shares tab, and click on and edit the appropriate SMB share. In the Public line; Guests Allowed would match the Shared Folder permission Others - read only from above, and Public - No would match Others - none.


    (**Side note - SMB network share permissions, set on the Public Line, can not override the permissions set on the Shared Folder under it. It can only further restrict.**)


    If you use Public - NO; in SMB extra options, I use the statement write list = @users to insure users have access to the SMB share and can write to the share, despite the setting of the SMB Read Only option. (**Note: this "write list" statement in extra options is not necessary for what you're trying to do. I use it as a preference for other things I do with SMB shares, like setting "Read Only" when allowing temporary guest access.**)
    ___________________________________________________________________________


    If you want exclusive access to a network share, under Access Rights Management, Group, you'd need to create a new group and add only your user name to it.
    Create your own personal Shared folder and using the ACL button, change the Group setting to the new group you just created, and Others - none.
    Finally, create a new SMB/CIF share, on the shared folder created above, and set Public to NO .
    ___________________________________________________________________________


    If something goes wrong, you can undo permissions settings by changing Shared folders to Others - Read/Write , and SMB/CIF shares to Public - Guests Allowed.


    (I hope this helps to get you on track.)

  • In my scenario, I can ONLY get the Windows user write access by putting a check under Read/Write in the top section.

    • Offizieller Beitrag

    In my scenario, I can ONLY get the Windows user write access by putting a check under Read/Write in the top section.

    And you're doing this using an ACL by name? Believe me when I say, and I'm not trying to be rude, that's unique to "your scenario". This is a general guidance thread only, that couldn't possibly cover the near endless permissions possibilities.


    While I plan to do a permissions section for the user guide; it couldn't possibly contain enough to throughly explain permissions in's, the out's, and what could go wrong.
    _________________________________________________________


    If you look closer at your permissions situation, which is what I'd do, keep this in mind:


    Windows:
    When there's more than one permission involved, Windows permissions work on a boolean "OR", meaning if there are two permissions settings, the one that allows the most access is granted. (In AD domains, using a GPO, a no user or no access group can be created. But this is an exception. Admin's use it as a sort of "deny all" retirement of a user account, while retaining the account.)


    Linux:
    Linux basic, or more accurately termed "standard permissions" are; Owner (usually "root"), Group (frequently "users"), and Others (applies to all who are not specifically called out as the owner, or in the assigned group). These permissions are an integrated part of a Linux file or folder. "Extended Permissions", also referred to as ACL's, are not a standard part of a Linux file or folder. They're added as a "patch", in a file or folders extended attributes.


    Since I ran into some interesting permissions "weirdness", I read a white paper on the potential conflicts that can crop up between standard and extended Linux permissions. As it seems, unlike Windows where multiple permissions are handled as an "or" situation, granting the highest access; when Linux file/folder permissions have basic AND extended permissions assigned, it can become a boolean "AND" situation. In essence, if both permissions are not the same (and one of the two does not allow write), write permission can be denied. This has it's uses (for denying access to one individual in the users group) but that's not the "end all" of the conflict "weirdness".


    To keep is simple, and one could even say "reasonable", it's best to structure access around standard Linux permissions. While that has it's limitations, and can be inconvenient is some business cases, it's behavior is predictable and well documented. On the other hand, mixing the two permissions types together (standard and extended) can take one down a rabbit hole.

Jetzt mitmachen!

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