Proposal to remove confusing "security XX mask" parameters for 4.0.0

Jeremy Allison jra at samba.org
Tue Oct 2 22:41:01 MDT 2012


So let's be honest, does anyone really understand
and use the following share-level smb.conf parameters ?

security mask
force security mode
directory security mask
force directory security mode

For people who aren't aware of them, what they
do is provide AND then OR boolean operations
on any POSIX permissions that smbd sets when
mapping from a Windows NT ACL set onto a POSIX
ACL. The first two parameters are used when
setting ACLs on files, the second two when
setting ACLs on directories.

Their defaults are :

security mask = 0777
force security mode = 0
directory security mask = 0777
force directory security mode = 0

which means by default they have no effect
when clients are changing or setting ACLs.

We already have the following parameters:

create mask
force create mode
directory mask
force directory mode

which do exactly the same thing (provide
AND then OR boolean operations) when
smbd is *creating* files or directories,
rather than modifying ACLs.

Their defaults are:

create mask = 0744
force create mode = 0
directory mask = 0755
force directory mode = 0

The reasoning behind these sets of parameters
is that historically we wanted to allow UNIX
admins to set up a set of mask bits that we
would *absolutely* guarantee that smbd would
never allow from clients, or conversely a set
of forced bits that would always be set on
files or directories created by smbd.

Having 8 parameters for this seems like 
overkill, and has lead to much confusion
over the years.

What I'd like to propose is that we
remove the first 4 parameters:

security mask
force security mode
directory security mask
force directory security mode

for 4.0.0, and leave only the original

create mask
force create mode
directory mask
force directory mode

parameters, which will then be applied
on both create and ACL set operations.

This will simplify things quite a bit.

The reason for doing this now, at a late
stage of 4.0.0, is that breaking existing
smb.conf files is already something we
have done for 4.0.0, and so it's a good
time to get the fundamental changes in
now, rather than breaking everything
once in 4.0.0, and then breaking more
things in 4.1.0.

Thoughts and comments from the technical
crowd please ?

Cheers,

	Jeremy.


More information about the samba-technical mailing list