FW: patch for safer/saner permissions setting

[Cole, Timothy D.]

> Thanks for that patch. This is very close to the ideal
> semantics, but I'd like to change it a little.
> 
> Firstly, using the "force mode" but not the "create mask"
> is confusing (at least to me :-).
> 
> For that reason I'd like to change it to use 4 new parameters :
> 
> security mask
> force security mode
> 
> and 2 more for directories. These parameters would (if not
> set in the smb.conf file) be set to the same values as the
> create mask and force create mode parameters.
> 
	[Cole, Timothy D.] 

	Hrm; yes, security mask is probably a better name..

	[Cole, Timothy D.]  

> This allows by default the behavior not to change and also
> allows an admin to have complete control over the permissions
> that can be set by a user (and by default they'll be the same
> as the create restrictions).
> 
> I also think the idea of retaining the extended security 
> (setuid, sticky etc.) bits is a good one, but I'm not sure
> how to rationalize this with the current behaviour which
> prevents any Samba created file from containing any
> of these bits unless set in the "force mask".
> 
	[Cole, Timothy D.]  

	Any files that have these bits set (if they weren't in the "force
mask") either weren't Samba-created to begin with, or their permissions were
later deliberately modified from the Unix side, and the current
configuration options are really only applicable to file creation.  It is
broken behavior to force Samba creation restrictions on them after the fact,
then, especially without notifying the user.

	It is OK for Samba to rely on the create mask and force mode
parameters to dictate the permissions of a file at creation time, and it is
OK for Samba to prevent me from changing a permissions bit on an existing
file, but it is NEVER OK for Samba to change a permissions bit that I did
not try to change on an existing file.  This, of course, applies for the
extended bits just as much as it does for the normal bits.

	(if changing a bit has side-effects for other bits naturally under
Samba's host OS, then that is another matter, and Samba's only
responsibility is not to defeat that behavior -- note the recheck of
permissions after a dos_chown() in my patch which prevents things like a
suid bit from being re-applied after a chown)

	[Cole, Timothy D.]  

> What do you think ?
> 
> Regards,
> 
> 	Jeremy Allison,
> 	Samba Team.
> 
> -- 
> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------