LinuxQuestions.org - weird permissions in new folder created over samba when extended ACLS are used

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - weird permissions in new folder created over samba when extended ACLS are used (https://www.linuxquestions.org/questions/linux-server-73/weird-permissions-in-new-folder-created-over-samba-when-extended-acls-are-used-846298/)

weird permissions in new folder created over samba when extended ACLS are used

Hello everyone,
i'm setting up a common public folder on a file server, but I seem to be getting some permission differently to what I expected.

The folder is /temp which is a separate drive. The fstab entry is:

Quote:

/dev/hda2 /temp xfs defaults 1 2

with permissions:

Quote:

root@halki:/# ls -l /
drwxrwsr--+ 9 root shares 4096 2010-11-24 17:52 temp/
.... (other results truncated)

and its extended ACLS are:

Quote:

root@halki:/temp# getfacl /temp/
getfacl: Removing leading '/' from absolute path names
# file: temp/
# owner: root
# group: shares
user::rwx
group::rwx
other::r--
default:user::rwx
default:group::rwx
default:group:users:r-x
default:mask::rwx
default:other::r--

The 'shares' group is the default write group in /temp (I preffered to use something other than the 'users' group which is default for every new user).

additionally, smb.conf (samba set to 'share' mode) exports this folder to the network as:

Quote:

[temp]
comment = Temporary file space
path = /temp
read only = no
public = yes
force group = shares
inherit permissions = yes
inherit acls = yes

So I would expect that when I create a new subfolder within /temp from over the network,
it would inherit the permissions from /temp directly or at least from its default ACLs entries.

in contrast to that I get

Quote:

drwxrwsr-x+ 2 nobody shares 6 2010-11-24 18:24 test/

So the others get an execute permission too...

where does my train of thought fail me ?:)

thank you for your help!

EDIT: obviously I want the permissions to look like those of /temp folder. that is rwxrwxr--

Hi !
What about your "directory mask" in smb.conf ?
I have no way to test it now, but as it defaults to 755 it could be your problem.

well that would solve the problem, but i'm looking for the reasoning behind this...

default ACL for others is ---

it should count somewhere. shouldn't it?

A question puzzles me : Why would you give r-- right for others on your directory ? This will not even allow them to enter/read the directory as r-x is required for that. In fact, samba is doing fine in allowin r-x on your sub-folders as this really corresponds to a read-only setting. What about if you create a file instead ?
I really think you should manage this with the 'directory mask' and 'create mask' options in your share's parameters in smb.conf.

actually you are correct. thought that others would be able to read from the folder (but not execute anything in it).

so there is no difference between --- and r-- for folders?

as for the directory mask of samba, indeed it solves the problem, BUT don't you agree that samba's permissions are ANDed with the directory permissions? So shouldn't the sambas dir 755 be ANDed with the default ACLs (which are there to be inherited) 774 of /temp? that should end up giving subfolder permissions of 754. Instead I get 775...and that seems odd to me :)

Creating a new file over samba however I get the expected behaviour. Ie. file permissions are 774...

Hi,

The cause is the 'inherit acls' parameter you set to yes. Quoting from the samba documentation,

Quote:

This parameter can be used to ensure that if default acls exist on parent directories, they are always honored when creating a new file or subdirectory in these parent directories. The default behavior is to use the unix mode specified when creating the directory. Enabling this option sets the unix mode to 0777, thus guaranteeing that default directory acls are propagated.

.

It seems you cannot do without setting the 'directory mask' parameter.
As for the 'r--' permission on a folder, it has the same effect as '---' indeed. But I wouldn't say this is equal as the read permission is set so it could lead to some undetermined leak.

Hope this helps.