Permisions

[Ries van twisk]

Hi all,

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
kernel.
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
samba.

SO it does have some advantages, there are a lot of disadvantages.


Just my $0.02

Ries




0

"Justin L. Boss" wrote:
> 
> I have a question.
> 
> The limitation of Samba seem to me to be because of the differences of UNIX
> 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 that
> 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 the
> 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 information.
> 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 more
> 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. Don't
> 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.