[Samba] Why isn't Samba honouring UNIX permissions? [NOT PROTECTIVELY MARKED]

[Gaiseric Vandal]

What do the permissions look like in Windows?  I am using Samba 3.0.x on 
Solaris 10 ZFS file systems, so this may not be relevant in your case.

I found that sometimes Samba/Windows interprets permissions differently 
than unix.  E.g. a 660 permission in unix sometimes results in a Windows 
access control entry of "deny everyone."    However, at least by 
default, the combination of "windows" permissions and "unix" permissions 
should result in "most restrictive" - which means if you can't do it in 
unix you should not be able to to it Windows (or even if you can do it 
in unix you may still be unable to do it in Windows.)

Are you able to "su - somewindowsuser" under unix to verify what they 
can/cannot do what you expect?     The "default:user:rwx" and 
"default:group:rwx" acls look like they may be an issue.  Although the 
syntax for acl's changed with ZFS so I am a little rusty with ufs acl's.





On 03/04/2010 08:17 AM, Nigel.Pain at scotland.gsi.gov.uk wrote:
> Classification: NOT PROTECTIVELY MARKED
>
> Solaris 9
> Samba 3.4.5
>
> I know this isn't the sort of query that gets much response but I'd be
> really grateful of any advice people can offer.
>
> I'm getting really fed up with Samba as I've never been able to make it
> work properly. Either I'm missing something basic (probably) or it just
> doesn't behave in the way I think it should!
>
> The main issue I'm having is that it doesn't appear to honour the
> permissions that I have set in Solaris. I'm using UNIX acls so a
> directory can have a permissions set something like this:
>
> $ getfacl OCEA
>
> # file: OCEA
> # owner: root
> # group: sdmu
> user::rwx
> group::rwx              #effective:rwx
> group:ocea:r-x          #effective:r-x
> mask:rwx
> other:---
> default:user::rwx
> default:group::rwx
> default:group:ocea:r-x
> default:mask:rwx
> default:other:---
>
> Now, under UNIX, a member of group sdmu should be able to read, write
> and delete within the directory, a member of group ocea should only be
> able to read and other users shouldn't be able to open it even. I would
> expect the same to happen via Samba. However, any domain user that maps
> to a local user can do anything they like within the directory.
>
> I'm using Domain security but this happens with server security too. I
> wanted to use ADS security but I'm coming up with the Solaris
> NGROUPS_MAX problem (most of our domain users have in excess of 70 group
> memberships). Here's the smb.conf:
>
> [global]
>          unix charset = LOCALE
>          workgroup = OURDOMAIN
>          realm = OURDOMAIN.GOV.UK
>          server string = OURSERVER
>          bind interfaces only = Yes
>          security = DOMAIN
>          password server = dc.ourdomain.gov.uk
>          log level = 2
>          log file = /usr/local/samba/var/log.%m
>          max log size = 10000
>          domain master = No
>
> [testshare]
>          path = /testshare
>          read only = No
>          acl group control = Yes
>          create mask = 0775
>          directory mask = 0775
>          inherit permissions = Yes
>          inherit acls = Yes
>
> Many thanks.
>
> Nigel Pain
> The Scottish Government
> Corporate Systems Support
>
>
> ********************************************************
>
> This e-mail (and any files or other attachments transmitted with it) is intended solely for the attention of the addressee(s).  Unauthorised use, disclosure, storage, copying or distribution of any part of this e-mail is not permitted.  If you are not the intended recipient please destroy the email, remove any copies from your system and inform the sender immediately by return.
>
>
>
> Communications with the Scottish Government may be monitored or recorded in order to secure the effective operation of the system and for other lawful purposes.  The views or opinions contained within this e-mail may not necessarily reflect those of the Scottish Government.
>
> ********************************************************
>
>
> The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
> Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
>