FW: patch for safer/saner permissions setting

[David Collier-Brown]

Jeremy Allison wrote:
> 
> David Collier-Brown wrote:
> 
> >         Logically, I can argue that the special bits
> >         should be honored/retained by Samba if the
> >         ordinary create mask allows them, and forced
> >         into place if the force masks sets them.
> >
> >         That's sufficient, and probably necessary
> >         (in the adademics' sense of "necessary").
> 
> Yeeesssss, sort of, but currently all examples are given
> without including the special bits, with the result
> that Samba never creates files with the group setuid
> bit set (for BSD semantics on directories for example).

	And we'd be silly to break that!
 
> A counter arguement is that if an admin sets up directory
> with the BSD inherit group semantics then, as there is no way
> in the NT permissions dialog to set it then Samba should
> just leave the special bits alone on a security chane SMB.

	Ok, off we go on one of my favorite hobby-horses (;-))

	It's quite possible, over the period from 2.1 to 2.2,
	to
	    - start out compatible with 2.0 while adding functionality,
	    - change in a manner which is not intrusive, and
	    - end up with a different behavior.

	I won't go down the "how it works" alley unless asked, but here's
	a concrete example of how it **could** be done in Samba.

	In 2.1, make a visible change:
		i) add the ability to use the special bits in all masks
		ii) change the default "permit" mask include all the
		   appropriate extra bits, and the default force mask 
		   (as it is now) contain none of them.
		iii) change the code to warn if a user-set 
		   permit mask doesn't include them, AND 
		   a file would thereby lose the bits, at
		   log leave 0 (you need a "whoops" bit temporarily
		   to do this).
		  HOWEVER, do NOT turn off the bits until 2.2.

	During this period:
		90% of the users won't ever care
		 9% will notice, care and fix their masks
		 1% will complain that the permit mask is broken (:-))

	As of 2.2, make another, less visible change
		i) honor the permit mask and unset the bits
		ii) On hitting a file with them set, 
		   logging the removal at level 0 with a
		   message about what to change in the mask to
		   get the desired behavior. Drop the "whoops" bit.

	Now:
		98% won't care
		 1% will be pleased you finally fixed the permit mask
	         1% will ask what happened to the sticky bit (;-))

	This is actually more complex than the normal case of
	"transparent continuous maintenance", as there is a
	capability that's not fully implemented in 2.1: normally
	one just can add capabilities in to at that stage.

	
--dave
[This is from a talk by Paul Stachour on how the old ARPAnet
 did continuous software changes in Honeywell NIMs while the 
 net was running, and occasionally backed them out when they 
 didn't work, all without reboots or interruptions]
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | http://java.science.yorku.ca/~davecb
Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb at canada.sun.com