[Samba] Prevent Samba from setting the execute bit (with inherit ACLs set to YES) ?

f.pospischil at telenet-ag.de f.pospischil at telenet-ag.de
Wed Aug 6 09:24:27 GMT 2003


Hi there ....

Linux (redhat 9.0) does not set the execute-bits for new files, (even with
umask set to 777) by default.

Why does samba ?

When default ACLs are set, samba explicitly sets the mode to 777 for new
files and directories, and then somehow corrects them according to the
default ACLs.
As the default ACLs have to contain an executable bit to allow access to
newly created directories, every new file will have this bit set, too.

Is it possible to tell samba to treat new files and new directories in
different ways to reflect standard unix behavior ? ( i.e. set mode to 666
for files and 777 for dirs)

BTW, even setting the force security to 666 does not prevent the file from
beeing created with 777 ...

We use samba 2.2.8a on redhat 9.0 with XFS as a plattform for cross-system
development.

Help is very much appreciated ...

Frank Pospischil
Leiter IT
Telenet AG Rhein-Main
Darmstadt, Germany
Web: http://www.telenet-ag.de





From:        David Morel <david.morel at amakuru.net>        01.07.2003 12:45
To:     f.pospischil at telenet-ag.de
cc:     Samba Mailing List <samba at lists.samba.org>
Subject:        Re: [Samba] Prevent Samba from setting the execute bit (with    inherit 
ACLs set to YES) ?


...
> have you read the manual, or did i not understand your question properly 
?


Both ist true :-)

The question was :
Is it possible to create files on a sambaserver (from a Windows Client of 
course) with no execute bit set, when "inherit ACLs" is set to "yes" ?
(Not in theory, I read th manual and I understood that samba forces 777 
for new files to ensure ACLs to take effect.)
I hoped there would be someone who is also interested in "as close as 
possible to Unix-Standard-behavior" and provides a patch that creates 
files with the mode given by "create mask", not hardcoded 777.

Thanks for your Question, I hope the topic is clearer now...

Frank




More information about the samba mailing list