SOLVED CIFS share unauthorized access

[nojohnny101]

So I have setup multiple users with their own datasets each and have them mounting it by first opening a SSH terminal (they are all accessing from macs, through terminal and finder) and then mounting the drive through a smb://localhost:15448 connection. Everyone connects with Private/Public keys.

this has worked fine but when they go to mount, all the drives that are currently being shared from the FreeNAS box over CIFS are visible (even if they don't have permission to view or mount). That has been fine because normally when the said user tried to click on a dataset and mount it that they don't have any level of access to, finder refuses and says "don't have permission to view this network drive".

However one of these remote users alerted me to the fact that he could mount a dataset that he most definitely does not have read, write, or execute access to. I'm not sure what I am missing. I have gone through all relevant settings but he can still mount. The behavior on other datasets is working correctly (not mounting, giving permission decided message). What am I missing?

Here is the current setup for "user1" where "user1" can access the dataset "user2" and mount it successful

SSH permissions

CIFS Settings:

any ideas or what else I should try?

 

[anodos]

You can use "smbstatus" to view which ip addresses are connected to which shares using which usernames. Verify that they aren't somehow accidentally using someone else's credentials. Post contents of /usr/local/etc/smb4.conf as well. You might have something configured there that is breaking the permissions model. Additionally, you're using "unix" permissions types with CIFS shares. >:[

 

[nojohnny101]

ok thanks for the "smbstatus" command. i'm actually going to be with the user tomorrow in person so i will be able to troubleshoot from there. good to know though.

Verify that they aren't somehow accidentally using someone else's credentials.

I actually thought of that briefly but then ruled it out because I never gave him login credentials that would have been mine in addition to the fact that private/public keys are being used only (disable password login is checked for his username in accounts).

Additionally, you're using "unix" permissions types with CIFS shares. >:[

oh on don't tell me that! i read through the manual religiously when first starting and was under the impression that if you have a mixed environment, CIFS with UNIX permission was the best way to go.

All macs currently access the FreeNAS box but I wanted to be able to have a windows user access the same datasets if need be. And since AFP is supposedly on its way out, i thought CIFS with UNIX was the best. It wouldn't make sense to use Windows permission with all mac machines would it?

NOTE: I can see you have a lot of write-ups on CIFS shares, do you strictly run CIFS?

here is the smb4.conf:

Code:

[global]
    server max protocol = SMB3
    interfaces = 127.0.0.1 10.0.1.44
    bind interfaces only = yes
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    oplocks = yes
    deadtime = 15
    max log size = 51200
    max open files = 461792
    logging = file
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    getwd cache = yes
    guest account = nobody
    map to guest = Bad User
    obey pam restrictions = yes
    directory name cache size = 0
    kernel change notify = no
    panic action = /usr/local/libexec/samba/samba-backtrace
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    server string = FreeNAS Server
    ea support = yes
    store dos attributes = yes
    lm announce = yes
    time server = yes
    acl allow execute always = true
    dos filemode = yes
    multicast dns register = yes
    domain logons = no
    local master = yes
    idmap config *: backend = tdb
    idmap config *: range = 90000001-100000000
    server role = standalone
    netbios name = AXIO
    workgroup = WORKGROUP
    security = user
    pid directory = /var/run/samba
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 1
    ea support = no
    store dos attributes = no
    map archive = no
    map hidden = no
    map readonly = no
    map system = no
    

[user3]
    path = /mnt/tank/user3
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    vfs objects = zfs_space zfsacl aio_pthread streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare
    

[family]
    path = /mnt/tank/family
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-6m
    shadow:snapdirseverywhere = yes
    vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare
    

[user2 files]
    path = /mnt/tank/user2
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-6m
    shadow:snapdirseverywhere = yes
    vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare
    

[user1]
    path = /mnt/tank/user1
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-6m
    shadow:snapdirseverywhere = yes
    vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare

 

[nojohnny101]

well I physically was with "user1" today and had him login to the server over SSH and then mount the datasets. here the output of "smbstatus" when he was logged in and mounted both his dataset "user1/" and the dataset he is not supposed to be able to mount "user2/"

everything checks out with permissions? what am I missing? i would like to figure this out and why it happened before just nuking the user and resting his login credentials to see if that fixes it.

 

[SweetAndLow]

It looks like to me that user1 and user2 directories both have the same group. So if user1 is in 'nogroup' then they have access to read everything in user2 directory. What groups does user1 belong to? Also group permissions are funky when using unix permissions over smb.

 

[anodos]

It looks like to me that user1 and user2 directories both have the same group. So if user1 is in 'nogroup' then they have access to read everything in user2 directory. What groups does user1 belong to? Also group permissions are funky when using unix permissions over smb.

+1.
It looks like both users are members of "nogroup". Try changing datasets so that they're owned by user1:wheel and user2:wheel then repeat the test.

 

[nojohnny101]

Ok thanks guys for the help. I guess I need some clarification on something I thought I understood:
I thought "nogroup" was used in cases where an administrator wants a particular user to not be a member of any group. Such that putting them in "nogroup" actually is kind of like a black hole and does not group them into anything. I was under the impression that if "user1" and "user2" were both in "nogroup", there would be no relation or similarity shared because of being assigned "nogroup" as far as FreeNAS is concerned.

This is not correct?

 

[SweetAndLow]

Not correct, nogroup is just another name for a group and it had its own gid. Ignore the letters and word they make up, it's just a simple group.

 

[nojohnny101]

Ok thank you for clearing that up. That is a bit confusing and I think I picked up that thought because I remember reading another post on the forum from a guy advising that to someone else, using "nogroup" when one doesn't really want that user in a group. Now I know!

Is not putting them both in group "wheel" create the same problem as putting them both in group "nogroup"? Or does group "wheel" have special properties?

 

[SweetAndLow]

There is no such thing as a special group. What you need to do is make sure your users don't have group permissions to read or write on other users directors. What was suggested to you is to change the group ownership to something that isn't a group your users are in. Wheel is just a group that your probably don't have have your users part of. Normally only root is in that group. There are lots of ways to solve your problem you just need to pick one or give is more information like requested.

 

[anodos]

Ok thank you for clearing that up. That is a bit confusing and I think I picked up that thought because I remember reading another post on the forum from a guy advising that to someone else, using "nogroup" when one doesn't really want that user in a group. Now I know!

Is not putting them both in group "wheel" create the same problem as putting them both in group "nogroup"? Or does group "wheel" have special properties?

The point is to set the share so that it's owned by a group of which your users are not members.

 

[nojohnny101]

The point is to set the share so that it's owned by a group of which your users are not members.

This is what made it click for me. Thanks to both of you.

I'm going to have to go back through my permissions setup and rework somethings because some of it based upon the previous false understanding I had about "nogroup".

Thanks!