Project

General

Profile

Feature #11390

UNIX permissions & CIFS shares: group member cannot modify an existing file with 660 permissions

Added by Brett Keller almost 6 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Important
Assignee:
Warren Block
Category:
Documentation
Target version:
Estimated time:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

FreeNAS Mini


Description

Summary:
When using UNIX permissions on a given dataset, users who are not owners of a file but are members of the owning group are denied write access via CIFS when the file's mode is 660.

Expected behavior:
Users belonging to the owning group (but who are not the owning user) should have read-write access, while non-owners are denied all access.

Actual observed behavior:
Members of the owning group (but who are not the owning user) are denied write access via CIFS. Read access works as expected. Write access via the shell behaves normally; it is only access via CIFS that is blocked.

Steps to reproduce:
  1. Create a new group named "test_rw"
  2. Create new users "testuser1" and "testuser2", both of which have "test_rw" auxiliary group membership
  3. Create a new dataset named "test" with "Share type: UNIX"
  4. Change permissions on the "test" dataset in the following way:
    • Change "Owner (group)" to "test_rw"
    • Grant read, write, and execute permissions for "owner" and "group"
    • Revoke read, write, and execute permissions for "other"
  5. Create a new CIFS share on the "test" dataset with the following settings:
    • Share name: "test"
    • Uncheck "Apply Default Permissions"
    • Add "create mask = 660" to "Auxiliary Parameters"
    • Add "directory mask = 770" to "Auxiliary Parameters"
  6. On a Windows client, connect to the "test" share as "testuser1"
  7. Create a new text file named "Shared.txt", enter some arbitrary text content, save, and close the file
  8. Re-open "Shared.txt", make some changes, and save again to verify that modification of an existing file is working as expected
  9. Terminate "testuser1" connection to the "test" share and logout of the Windows client to clear the SMB session cache
  10. Login again to Windows, and connect to the "test" share as "testuser2"
  11. Create a new text file named "User2.txt", enter some arbitrary text content, save, and close the file just to verify that "testuser2" has read-write permissions for the directory.
  12. Open "Shared.txt", make some changes, and attempt to save the file
  13. Note that Windows responds by asking you to create a new file instead of saving over the existing one
  14. Also note that if you insist on saving over the existing file, Windows presents the error message "Access is denied"

It seems that the root of the problem is that NFSv4 ACLs are being parsed by the CIFS service, even though the dataset is declared to be using UNIX permissions. This is supported by the fact that either of the following two workarounds appear to solve the problem.

Workaround #1:
Set a non-default ACL on "Shared.txt" that explicitly allows the owning group read-write access.


 [root@freenas] /mnt/pool/test# ls -la Shared.txt
 -rw-rw----  1 testuser1  test_rw  33 Sep  8 16:15 Shared.txt

 [root@freenas] /mnt/pool/test# getfacl Shared.txt
 # file: Shared.txt
 # owner: testuser1
 # group: test_rw
             owner@:rw-p--aARWcCos:------:allow
             group@:rw-p--a-R-c--s:------:allow
          everyone@:------a-R-c--s:------:allow

 [root@freenas] /mnt/pool/test# setfacl -m group@:rw-p--aARWcCos:------:allow Shared.txt

 [root@freenas] /mnt/pool/test# ls -la Shared.txt
 -rw-rw----+ 1 testuser1  test_rw  33 Sep  8 16:15 Shared.txt

 [root@freenas] /mnt/pool/test# getfacl Shared.txt
 # file: Shared.txt
 # owner: testuser1
 # group: test_rw
             owner@:rw-p--aARWcCos:------:allow
             group@:rw-p--aARWcCos:------:allow
          everyone@:------a-R-c--s:------:allow


Now "testuser2" can successfully save changes to "Shared.txt", though this file now has an ACL and no longer uses simple UNIX permissions.

Workaround #2:
Override the list of VFS Objects in the FreeNAS GUI by specifying a complete list in the "Auxiliary Options", but remove the "zfsacl" module from the list.
  1. Get the current set of loaded VFS modules for the "test" share:
    
     [root@freenas] /mnt/pool/test# testparm --section-name=test --suppress-prompt | grep "vfs objects" 
     Load smb config files from /usr/local/etc/smb4.conf
     Processing section "[test]" 
     Loaded services file OK.
             vfs objects = zfs_space, zfsacl, aio_pthread, streams_xattr
    
  2. Edit the "test" share in the FreeNAS GUI
  3. Under "Auxiliary Parameters", add an additional line to override the FreeNAS VFS module defaults, removing "zfsacl" from the list:
    vfs objects = zfs_space, aio_pthread, streams_xattr
  4. Save your changes in the GUI
  5. Restart CIFS services and verify your "vfs options" line is overriding the default as expected:
    
     [root@freenas] /mnt/pool/test# service samba_server restart
     Performing sanity check on Samba configuration: OK
     Stopping winbindd.
     Waiting for PIDS: 10446.
     Stopping smbd.
     Stopping nmbd.
     Waiting for PIDS: 10438.
     Performing sanity check on Samba configuration: OK
     Starting nmbd.
     Starting smbd.
     Starting winbindd.
    
     [root@freenas] /mnt/pool/test# testparm --section-name=test --suppress-prompt | grep "vfs objects" 
     Load smb config files from /usr/local/etc/smb4.conf
     Processing section "[test]" 
     Loaded services file OK.
             vfs objects = zfs_space, aio_pthread, streams_xattr
    
  6. Now "testuser2" can successfully save changes to "Shared.txt". I was unable to find documentation on the ZFS-specific Samba VFS modules, so I cannot say what other effects removing "zfsacl" might have on the share.

Associated revisions

Revision 1980cc64 (diff)
Added by Warren Block over 4 years ago

Clarify permission usage. Ticket: #11390

History

#1 Updated by John Hixson almost 6 years ago

  • Status changed from Unscreened to Closed: Not To Be Fixed
  • Target version set to 261

Use windows datasets for windows shares. UNIX style permissions are not supported.

#2 Updated by Brett Keller almost 6 years ago

  • Category changed from 57 to Documentation

Wait, what?? Aw, geez. I had understood the FreeNAS docs as recommending UNIX style permissions for all shares (including CIFS) whenever the connecting clients are using a mix of operating systems. It sounds like I've been setting up a lot of datasets on a lot of servers incorrectly this whole time, and I've got a lot of fixing to go do!

Am I understanding you correctly that all datasets that are to be shared via CIFS should be setup using Windows permissions, period?

If that's the case, then I now think this is a documentation bug, and I have changed the category accordingly.

Here's the part of the documentation that I read as saying I should be using UNIX permissions for my CIFS shares:
In Section 8.1.2, it describes "Permission Type" as,

choices are Unix, Mac or Windows; select the type which matches the type of client accessing the volume/dataset

My thought process then goes, "Well, I know I'm going to be setting up a CIFS share, but I plan to have Windows, Mac, and Linux clients all connecting to the same share. What should I set 'Permission Type' to in that case?"
My question then appears to be addressed in the immediately following paragraphs:
If you have a mix of operating systems or clients will be accessing the volume/dataset using a non-CIFS share, select the Unix “Permission Type” as all clients understand them.

The Windows “Permission Type” augments traditional Unix permissions with ACLs. Use the Windows “Permission Type” for CIFS shares or when the FreeNAS® system is a member of an Active Directory domain.

That first paragraph presents an OR statement, and my use case satisfies the first condition of that OR ("If you have a mix of operating systems") because I have a mix of Windows, Mac, and Linux machines that will all be using CIFS to connect to my FreeNAS share. According to that paragraph, I should therefore select the Unix "Permission Type" for my CIFS share serving multiple OS's.

Of course, this is then contradicted by the second paragraph that does indeed say, "Use the Windows 'Permission Type' for CIFS shares". I have always found this contradiction puzzling, because the documentation is essentially telling someone in my use case to perform two different, mutually exclusive actions based on non-mutually exclusive conditions.

At this point in reading the docs, attempting to resolve the contradiction, my thought process then goes, "Well, I can't do both of these things. The part about having 'a mix of operating systems' is listed first, so it's probably the most important. Maybe they only mean for me to 'fall through' into the second paragraph if I have a group of clients all using a single OS who happen to connect via a CIFS share, and only in that case should I use Windows permissions."

If I'm now understanding you correctly, it sounds like "Permission Type" is more about the sharing protocol than it is about the client operating system. If I want a CIFS share, I should always choose Windows permissions; if I want an NFS share, I should always choose UNIX permissions, and if I want an AFP share, I should always choose Mac permissions. Do I have that right? If so, then I would request that the documentation is updated to better reflect this and to do so in as simple terms as these.

Thank you.

#3 Updated by Jordan Hubbard almost 6 years ago

  • Status changed from Closed: Not To Be Fixed to Unscreened
  • Assignee changed from John Hixson to Dru Lavigne
  • Priority changed from No priority to Important

Over to Dru, if we are indeed continuing to recommend these sorts of worst practices in our docs!

To be very clear, the docs should state the following:

1. For sharing with Windows clients, the share type must be set to Windows
2. For sharing with Unix clients, the share type must be set to UNIX
3. For sharing with Macintosh (or other AFP) clients, the type must be set to Mac

Sharing a single dataset to multiple client types is NOT supported as the differences in the various file locking and permission semantics across these different operating systems may cause data corruption (in the case of lock contention) or unexpected permissions behavior. When the Windows type is used, Unix permission changes are in fact disallowed (chown/chmod does not work) as those changes would also cause the loss of important Windows ACLs.

If you must share the same dataset across heterogenous operating systems, then pick the same sharing protocol. Unix machines are capable of speaking SMB, and Windows machines are capable (albeit poorly) of speaking NFS. Macintosh clients can do any of the above (and are quite happy to use NFS or SMB as well as AFP).

#4 Updated by Dru Lavigne almost 6 years ago

  • Status changed from Unscreened to Screened

#5 Updated by an odos almost 6 years ago

Jordan Hubbard wrote:

Over to Dru, if we are indeed continuing to recommend these sorts of worst practices in our docs!

To be very clear, the docs should state the following:

1. For sharing with Windows clients, the share type must be set to Windows
2. For sharing with Unix clients, the share type must be set to UNIX
3. For sharing with Macintosh (or other AFP) clients, the type must be set to Mac

Sharing a single dataset to multiple client types is NOT supported as the differences in the various file locking and permission semantics across these different operating systems may cause data corruption (in the case of lock contention) or unexpected permissions behavior. When the Windows type is used, Unix permission changes are in fact disallowed (chown/chmod does not work) as those changes would also cause the loss of important Windows ACLs.

If you must share the same dataset across heterogenous operating systems, then pick the same sharing protocol. Unix machines are capable of speaking SMB, and Windows machines are capable (albeit poorly) of speaking NFS. Macintosh clients can do any of the above (and are quite happy to use NFS or SMB as well as AFP).

Is there some technical reason why 'zfsacl' (and related nfsv4:* parameters) can't be treated like other samba vfs modules, which the user can enable or disable through the WebGUI?

There are some cases where a person may legitimately wish to use alternative, old-style samba permissions schemes. It is also consistent with the way users were given more control over vfs modules in 9.3 (some of which, like vfs_ACL_xattr, are not entirely compatible with zfsacl).

You can still say it's unsupported, but give users the ability to generate a properly working config. A decent amount of people coming to the forums with permissions problems explicitly want to use older-style 'unix' permissions. I'd rather not respond with 'you're holding it wrong'.

#6 Updated by Jordan Hubbard almost 6 years ago

  • Status changed from Screened to Closed: Not To Be Fixed

BRB: We've been down this road before, and we got a lot of tickets from users who hung themselves trying to do this. Those users are, indeed, holding it wrong and can accomplish their goals using the more modern methods - they don't need to return their boxes to the bad old days when Samba lied and pretended to offer Unix permissions to Windows clients.

#7 Updated by Brett Keller almost 6 years ago

Could someone with access please change the status of this bug from "Not To Be Fixed" back to "Screened"?

I understand Jordan Hubbard's position that this is not to be fixed in terms of being a "CIFS" category bug, but in light of that, the bug was changed into a "Documentation" category bug, and I believe it is still valid in that context (as explained above) and is in need of being addressed. Thanks.

#8 Updated by Dru Lavigne almost 6 years ago

  • Status changed from Closed: Not To Be Fixed to Screened

Not sure why status got changed as it was in my Screened queue. Back to screened.

#9 Updated by Jordan Hubbard over 5 years ago

  • Target version changed from 261 to 49

6 months old. Moving to FUTURE

#10 Updated by Vaibhav Chauhan about 5 years ago

BRB: this section needs to be done.

#11 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Target version changed from 49 to 9.10.3

Dru: I've updated this to 9.10.3, is this something you can pass along to warren or others to get wrapped up?

#12 Updated by Dru Lavigne over 4 years ago

  • Assignee changed from Dru Lavigne to Warren Block

Not sure if it will make 9.10.3 or not, but a rewrite of the Sharing chapter is in the doc team's queue.

#13 Updated by Warren Block over 4 years ago

  • Status changed from Screened to Resolved

#14 Updated by Brett Keller over 4 years ago

Thank you!

#15 Updated by Bimi Smoqi over 4 years ago

  • Tracker changed from Bug to Feature

#16 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Target version changed from 9.10.3 to 11.0

#17 Updated by Vaibhav Chauhan about 4 years ago

  • Target version changed from 11.0 to 11.0-RC

Also available in: Atom PDF