don_mccall at hp.com
Tue Sep 4 06:50:07 GMT 2001
Personally, having Samba implement NTFS security outside of
Unix permission bits/acl's worries me. The majority of the people
that I work with across the world implement Samba on *ux because
they need the file access from both *UX and Microsoft platforms,
and having two schemes for access to the SAME fileset on *UX
doesn't sound very friendly to me. Not to mention the other
pitfalls that have been mentioned here.
My view has always been that file access should be an OS function,
and that what is REALLY needed is an NTFS implementation for *UX,
so that access from *UX and Samba (or any of the other NT-like *UX
applications) are handled at the FS level.
If you have a drive on a PC formatted as fat, or fat32, for instance,
NT doesn't fake up NT permissions for that - you get what the FS
underneath is capable of.
A project to create a framework that would allow vendors to implement
a true NTFS filesystem for their OS'es, in my opinion, is where this
type of effort would be best spent.
Just an opinion,
From: Ries van twisk [mailto:riest at franksintl.nl]
Sent: Friday, August 31, 2001 11:45 AM
To: Justin L. Boss; Samba Technical
Subject: Re: Permisions
I do agree that it would be more simple to move from Unix permissions to
samba permissions using a ACL file or using ACL/EA which is now in the
I think that the samba code is much simpler without using unix
permissions (note that i'm not a Samba coder).
There is at least one downside. This would work if you access all
'samba' files using windows.
There are a lot of people out there that are doing real crossplatform
filesharing. And suddenly it does not work anymore because everyfile is
root:root 0600. Problem there...
Most of them are NFS users which needs the permissions. Right?
What about users homedirectory and mail files. A lot of people
(including me) are using the samba server as a mailserver aswell. So I
need the users and my system anyway.
ACL/AE is already in the samba code and Linux is now understanding
ACL/AE. And some filesystems are ACL/AE aware. For example xfs.
One other downside when using a ACL file is that samba always needs to
access two files instead just one. There are people outhere that really
have thoudens of files in one directory which really would slowdown
SO it does have some advantages, there are a lot of disadvantages.
Just my $0.02
"Justin L. Boss" wrote:
> I have a question.
> The limitation of Samba seem to me to be because of the differences of
> and NT, it is like trying to get a round block to fit in to a square hole
> when trying to get Samba and UNIX user, group, and permissions to work
> together. For example you have to keep two password files and you have to
> add UNIX user for all Samba users which makes it necessary for a lot of
> complicated scripts for all the different flavors of UNIX, not to mention
> the confusion it can cause when the UNIX permissions are different then
> of your write list. Also UNIX and NT permissions are totally different,
> limiting Samba in its security abilities and features, it also slows down
> its development. It appears that a lot of time and coding have been spent
> trying to get UNIX and NT to be compatible with each other. My question is
> why not separate Samba from UNIX. What I mean is instead of Samba using
> UNIX user to create files. Remove all UNIX account and just have Samba us
> the root account to create all files and directories ( root rwx --- ---),
> then Samba would take care of security by also create a small file with
> "acl%" (hard coded in Samba to not be visible and accessible in shares) in
> front of it like "acl%document.doc" ("document.doc" being the real name of
> the file). That acl file would contain the Access control list
> Then Samba would look at that acl file before granting access to the user.
> You would no longer need a UNIX' users or groups. There would also need to
> be a smb.group. Directories would be the same just a different symbol like
> "acl@" or whatever. There are so many problems that this would salve, no
> write list, no admin user, and so many others. The smb.conf file would be
> just for configuration. Opining the door for the Samba team to work on
> important things. I don't know, maybe all these little acl files will take
> up to much space, or maybe they can just be created and acl for file that
> are assigned special permission and a default acl will apply to all other
> files. I don't know, this is probably a stupid idea but I have to ask.
> run me to hard.
> Example of a ls
> ls -l
> -rwx------ 1 root wheel 2 Aug 31 09:39 acl%document.doc
> -rwx------ 1 root wheel 2 Aug 31 09:41 acl at stuff
> -rwx------ 1 root wheel 12124 Aug 31 09:42 document.doc
> drwx------ 2 root wheel 512 Aug 31 09:42 stuff
> example of a acl file:
> +Everyone 1111 1111 1111 1111 1111
> -john 1111 0000 1010 0000 1010
> +joe 1111 0110 0101 1110 0001
> + and - = allow and deny
> user name
> binary number:
> 1 bit = Full control
> 2 bit = modify
> 3 bit = read & execute
> 4 bit = read
> 5 bit = write
> the rest can be used for the advanced security settings.
More information about the samba-technical