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:

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
-rwxrw-r-- 1 bob sales 12345 2008-05-27 15:46

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

To unsubscribe from this list go to the following URL and read the