samba - May 2008 - Mapping of Unix groups to Samba user permissions

I ran into a problem today which surprised me, and after two hours of
reading and testing I am more confused than ever, so I feel the need
for a sanity check. It would be good to have a clear and authoritative
article about this somewhere; I thought it would be in either "Using
Samba" or in the HOWTO, but I don't see it there.

I am using Samba in several installations in homes and small businesses
that are all Windows desktops (typically XP Home edition) and Linux
servers (typically Fedora Core 8), and I use the Linux user database
(/etc/passwd + /etc/shadow) as the primary authentication. To make
this work, I edit the Windows registry to set EnablePlainTextPasswd=1.
(Why? When I started setting these systems up, it was Windows95 so
there was no authentication on the Windows side. To make use of
Windows administration tools, you need Windows XP Pro on the desktops,
and need to learn lots of windows stuff. My background is Unix, so
that seems like un-necessary money to give to Microsoft, plus a large
learning curve.)

In my standard setup, I create a Unix user group for each SMB
share (the shares reflect functional data groupings) and set
up unix groups of the users allowed write access to each share,
and in each share I make the tree of directories owned by
and writeable by that group with a set-group bit to propagate
that group ownership. Unfortunately, the group-write permission
will not propagate that way, so a cron job runs twice a day to set
group-write on all directories with the tree of each share.

This has worked really well for a long time.

Today, suddenly I see that a windows user cannot write to directories
that are not owned by him. It appears that the SAMBA proxy does
not get to use the group privilege. It may in fact only have the
user's PRIMARY group affiliation, not the secondary ones derived
from the definitions in /etc/group. This is quite painful.

Once I lost confidence, I started looking for places that documented
how the various definitions of access rights interact with each other.
In particular the interaction of Unix group rights versus Samba
userids (write list, admin users etc). Since the primary documents are
not clear, I find that various user-written notes on the web found by
Google have conflicting and often downright wrong information on the
topic.

My testing of this is hampered by me not knowing how much information
is cached in the SMB daemon and in the Windows redirector; i.e. when
I make changes to smb.conf, do I need to "sudo service smb restart"?
Do I need to reboot the Windows client? To logout and back in on
Windows? To disconnect the network drive from the share?

The server where this problem surfaced runs samba-3.0.28a-0.fc8
and I think yum updated this quite recently. It it likely that
the behavior changed an a recent Samba update?

Is there a good source of documentation that I just plain overlooked?

Should I be using a different mechanism to set up the access rights?

/ Lars Poulsen

Andras S. Haramasz wrote:
> Hi,
> Since I'm UNIX boy myself here is what I did
>
> Say a user belongs two mpim (management) and mpir (research) and perhaps a
> third one too mpig(generic)
> Management share
> ls -latd /mpi/Management
> drwxrws---  36 root mpim 4096 2008-05-27 21:34 /mpi//Management
>
> ls -latd /research/mpi.Research
> drwxrwsr--  48 root mpir 12288 2008-05-29 13:08 /research/mpi.Research
>
> This way no matter what the user's primary group is the share's
group
> ownership will be maintained. It doesn't matter the subsequently
created
> files directories owner either, since will inherit the parent
directory's
> group. Also, allows access to group members only. In other words
> chmod 2770 dirname
Yes, this is structurally similar to what I have been doing, and for
that to work, the samba client must have the same group access rights
as a unix user logged in with the same username.

What I was seeing here today was this:

[sales]
        comment = Sales Department
        path = /home/sales
        public = yes
        writable = yes
        write list = @sales
        create mask = 0775

Two users alan and bob both have the primary group "employee", but
/etc/group defies them both as members of "sales".

drwxrwsr-- 11 alan sales  4096 2008-05-27 12:34 /home/sales/Contacts
-rwxrw-r--  1 alan sales 12345 2008-05-27 08:58 
/home/sales/Contacts/expo.csv
-rwxrw-r--  1 bob  sales 12345 2008-05-27 15:46 
/home/sales/Contacts/cann.csv

Both alan and bob should be able to create files in Contacts, and to
modify the files. But in fact only alan could do that. When bob
tried to create a file, access was refused; the directory was mapped as
read-only to bob. When I changed ownership of the directory to bob,
bob had the access he needed. The FILES seemed to have the correct rights.

Now, a few hours later, you message confirmed it should work as I
thought ... and now it DOES work that way.

I still think an article that spells out the mechanism in some
detail would be helpful. If I added to the write list a username
that is not in the sales group, would that user have access, or
would the underlying unix permission bits still block him?
If the server instance runs as root and SIMULATES the file system
protection, arbitrary patterns are possible. If the server instance
runs under the userid of the logged-in user, keywords such as "write
list" and "admin users" can restrict access but not open it
beyond
what the user can do. I do not know the server's architecture,
so I cannot deduce the ground rules.

/ Lars Poulsen

On 5/30/08, Lars Poulsen <lars@beagle-ears.com> wrote:
Unfortunately, the group-write permission
> will not propagate that way, so a cron job runs twice a day to set
> group-write on all directories with the tree of each share.
BTW, you don't need a cron job to do that since samba can manage this
for you every time a file or directory is created.

Have a look at "force create  mode" and "force directory
mode" in smb.conf(5).

Setting

force directory mode  = 0020
force create mode = 0020

im smb.conf will ensure that any files/directories created will be
group-writable.

- Richard