Samba share access - need clarification

[Ganesan R]

Hi,

I have one samba share which is given with below access level in smb.conf

[backup]
comment = Unix share BACKUP
path = /backup
valid users = user1
public = no
writable = yes
browsable = yes
printable = no
create mask = 0755

At unix level, see the permissions..

#bdf
/dev/backup/lvol1 744194048 550112808 192565576 74% /backup

#ll -d /backup
drwxrwxr-x 29 sql dba 8192 Apr 20 14:12 /backup

At unix level this mount point is owned by sql:dba

#id user1
uid=1106(user1) gid=20(users)

At unix level user1 is not having write access to the mount point /backup.

As per my understanding, user should be able to write on the samba share /backup since we have given "writable = yes" in smb.conf file
But i am able to browse but not able to write/delete anything through samba.

If I change user1 group membership to dba, i am able to write/delete. Why is it so?
I think, unix permissions are irrelevant to samba. am I wrong or missing something?

Hope to hear from you...

[Steven E. Protter]

Shalom,

Change the mount point ownership.

sql:dba

That is why changing the group to dba works.

You can also use samba parameters to define group ownership of the share.

http://us1.samba.org/samba/docs/man/manpages-3/smb.conf.5.html

http://www.docs.hp.com/en/B8725-90079/ch07s02.html

Second example may be better. But your configuration includes valid users but not a definition of group ownership.

I'd try tweaking smb.conf before the mount point but in the end I'd do both.

SEP

[Ganesan R]

Hi,

Thanks for your reply SEB.

My questions is, unix permissions are relavant to samba access in any ways?

If yes, then why we need writable=yes or browsable=yes options? Access can be given purely based on unix permissions right..

It is my understanding only. It would be great if someone can clarify this..

[Jeff Gyurko]

Hi Ganesan,

I always thought and currently use Samba to share Unix filesystems to Windows and it's the Windows username where those tokens come into play. If user1 is on a Windows PC, they should be able to and see the backups share name where thay can browse and write different files in there.

The Unix permissions should be irrelevant to the share on Windows although I'm not 100% sure of that statement.

[Steven E. Protter]

Shalom,

If yes, then why we need writable=yes or browsable=yes options? Access can be given purely based on unix permissions right..

No.

If you set writable=no, and the directory has write privileges, users on the command line will be able to write but users using a samba client like windows will not be able to write.

If you are servicing samba clients you need to get the samba permissions right.

Directory permissions CAN interfere with samba clients. Best practice is to bring permissions, samba perms into sync to avoid unexpected results.

SEP

[Ganesan R]

Hi Jeff,

We don't need the same user account on windows PC. We can select "different user name" option when we map the drive, if we don't have same samba user account in windows.

[Heironimus]

UNIX permissions are absolutely relevant on Samba shares. You have a set of filesystem permissions and a set of share permissions, and access requires permission at both layers. The same thing applies to shares on a Windows server, where you configure permissions in both the Security tab and the Sharing tab.

Samba does let you override the user/group for filesystem activity with "force user" and "force group" in smb.conf, which would effectively negate the filesystem permissions in your situation.

[eric roseme]

CIFS/Samba has a kind of dual-factor security. The client username (often a Windows client) must authenticate to the domain (or server, depending .....). Authentication just proves the user is who he says he is - so this task is often done by a Windows domain controller or Samba DC. Next is authorization - what does this user's (UID) have access to on the Unix OS? At no time is the UNIX security on either a file or directory irrelevant.

"valid users" and/or "writable = yes" are filters that Samba applies to regulate access based upon the *authenticated* user - the user name, *not* the UID. Most of those share-level access parameters are administered this way. Try it: give a shared directory 775 and in smb.conf give the share "writable = yes" - you cannot write. Samba can regulate the authenticated user access, but cannot overrule the UNIX permissions by UID.

"force user" is a different story, as are some other parms (pretty much anything force). "force user" just assigns the authenticated user the UID of whatever the "force user" user is. Since smbd runs as root, it can do this, but I think it's confusing and insecure. In any case, even "force user" does not override the file/directory permissions - it just switches the authenticated user's UID for access.

So for the most part, Samba can take away access based upon username, but cannot grant access that has been denied by UID.

Eric