Network and Storage Protocols

Cifs share permissions not being enforced on unix volume

mciardullo
7,883 Views

Hello,

I have some volumes that are unix primarily but still shared on cifs. The problem is the default nt user right now is root which I want to change but I have to fix a lot of volumes that were carried over first. For right now though when I create a cifs share of a unix qtree it isn't enforcing the share permissions at all. Any domain user can access the share and since they are root the unix permissions give them full access. Even enabling accessbasedenum doesn't help. So now viruses that write to open shares are hitting these and it's causing a large problem. If anyone knows what I can do with this please let me know.

Thanks

5 REPLIES 5

aborzenkov
7,883 Views
For right now though when I create a cifs share of a unix qtree it isn't enforcing the share permissions at all.

Could you show output of "cifs shares share_name" where share_name is share for which permissions are not enforced? Is your system part of domain?

mciardullo
7,883 Views

Hi

The output for one of the shares is here

USILST76A> cifs shares ftp_ftpca

Name         Mount Point                       Description

----         -----------                       -----------

ftp_ftpca    /vol/ftp_ftpca                    CA DLP Scanning share Mike Mendelsohn

             ... access based enum supported

                        TANT-A01\dlpfsa / Read

It is happening to every share that is using a unix qtree and is being shared via cifs. It doesn't happen to mixed shares as it appears on mixed shares it enforces the share and ntfs permissions.

This is on a domain. I thought it was something in usermap.cfg but after removing the line I thought was the problem it's still not enforcing the share permissions.

Thanks

Mike

aborzenkov
7,883 Views

I cannot reproduce it, at least in simple test. Running simulator in WORKGROUP mode and creating a share limited to specific group correctly denies access to a user not in this group.

simsim> qtree status

Volume Tree Style Oplocks Status

mciardullo
7,883 Views

I have also seen now if I create a cifs share and put a unix qtree under it that the share permissions are enforced at the top level but not on the qtree

for example if I create a unix qtree under a share that is ntfs and that qtree is unix then a user can't open \\share but can open \\share\unixqtree even though there is no share for that spot specifically.

aborzenkov
7,882 Views

You confuse share level and filesystem level permissions.

To be able to access
server\share\folder<file:///
server\share\folder> user must first have permissions to connect to
server\share<file:///
server\share>. If (s)he is not allowed to do it, there will be error right away and no way to access any file and/or folder inside this share at all. Your initial question was about share level access. And this is controlled by share ACL.

Once user connects to share (assuming necessary permissions are granted) access to individual file(s) and/or folder(s) in this share is controlled by file ACL. For Unix qtree these ACLs are reduced to standard Unix file owner, group and mode bits. For access check Windows user is mapped to Unix user and access is verified using standard Unix rules. If all your users are mapped to root, then every user has access to every file (on Unix qtree).

Please read TR-3490 about multiprotocol access to NetApp.

Public