Here's my setup from smb.conf:
[projects]
comment = Projects
path = /usr/local/projects
username = +users
valid users = +users +smbadm
force group = users
writeable = Yes
create mask = 0664
directory mask = 02775
Permissions of /usr/local/projects looks like:
drwxrwsr-x me users /usr/local/projects
I (user "me") creates a file "foo" on the
"projects" share, say, with
notepad.
Permissions on "foo" look like:
-rw-rw-r-- me users foo
Now, "me" can read, write, and do what I want with "foo".
Like check it into Visual Source Safe (VSS). VSS then issues (as "me")
a change to the permissions to be read-only. All is fine with chmod.
Permissions on "foo" now look like:
-r--r--r-- me users foo
Now, here's the problem. My friend, "friend", also creates a file
"bar"
on the "projects share, say with notepad.
Permissions on "foo" and "bar" look like:
-r--r--r-- me users foo
-rw-rw-r-- friend users bar
Now, my "friend" can read, write, and do what he wants with
"bar".
Like check it into Visual Source Safe (VSS). VSS then issues (as
"friend")
a change to the permissions to be read-only. All is fine with chmod.
Permissions on "foo" and "bar" look like:
-r--r--r-- me users foo
-r--r--r-- friend users bar
Now, my "friend" wants to check out "foo" from VSS and make
changes.
VSS issues a change permissions to add write permissions. Only
my "friend" can't because "me" owns "foo", and
only the owner of a file
can chmod it.
I see 2 problems:
1) On FAT filesystems, anybody can issue attrib changes, and this is
not restricted to the "owner" of the file. I don't think Samba
obeys
this when fstype=FAT for the share, and only allows the Unix owner
of the file to succeed when it issues a chmod, doing what Unix does,
not what the mapped filesystem would do on a real MS system.
2) On NTFS filesystems, anybody with ChangePermissions access can
issue attrib changes, and this is not restricted to the "owner" of the
file. I don't think Samba obeys this when fstype=NTFS for the share.
#2 is a bit wierd in that I *think* it probably "does the right thing"
when ACLs are involved. (i.e. anybody mapped to "owner" priveledges
can issue chmods and succeed, right?)
However, I'm using plain ole RH6.2 and not using ACLs, and so can't
really speak to their usefullness in this situation. Given that I don't
use ACLs, I (and Samba too) has no way to map the NT
"ChangePermissions"
access.
When I view permissions on the share, it indicates that the owner and
group have only a set of RWHAS permissions. It does not heed the NT
permissions of ChangePermissions, Delete, Take Ownership, etc.
I can understand this, as Samba has no way to map these NT ACLs to *nix
without some sort of ACL system on *nix.
What I'd like is either an option (or a permanent feature) to at least
grant *group* members the ability to chmod a file for NTFS fstype shares,
and probably grant any user the ability to chmod a file for FAT fstype
shares.
Has anyone already written such a patch/feature? Hints? Advice?
I am firmly convinced that this feature will solve *a lot* of the
permissions problems when using group access patterns.
Currently, my alternative is to "force user", but then you lose
the ownership trail from the *nix side of things.
Please CC me in your responses to the list.
PS. Thanks to tridge for responding personally within an hour of a
previous posting. I am continually amazed that only in the Open Source
world can you get that kind of support - first-hand from a primary
author of the software in question. I've not heard of an amount of money
that will get you that from large closed-source software companies
(e.g. Micro$oft, AOL/Netscape, Sun, Oracle, Intuit, ...).
Michael King
kingma@maritz.com
mike808@users.sourceforge.net
-------------- next part --------------
HTML attachment scrubbed and removed