FW: patch for safer/saner permissions setting

[Jeremy Allison]

Cole, Timothy D. wrote:
> 
> I originally sent this to samba-bugs, but didn't see any response...
> apologies if this has already hit CVS in some form or another; I can't use
> CVS from behind the firewall, and the samba-cvs archives seem to be b0rked
> as well.
> 
> --- begin forwarded message ---
> 
> > I've been playing with the permissions setting in 2.0.4 from an NT client,
> > and I'm finding that:
> >
> >   1. most of the time you want to allow the user to set permissions
> > broader than the creation mask if they want
> >
> >   2. existing permission bits always get silently mangled (by the creation
> > mask and the forced mode, as well as suid/sgid/sticky bits being
> > stripped), even when the user doesn't explicitly change them. This can be
> > downright  _dangerous_  in some cases, particularly with force mode
> >
> > The attached patch (against 2.0.4, although it should apply to 2.0.4b
> > fine) addresses the first issue by adding "allow mask" and "allow
> > directory mask" configuration parameters (defaulting to 0000), which are
> > ored with the creation mask when determining what permission bits the user
> > can set (so, if she desires, the sysadmin can allow users to set a more
> > liberal permissions than allowed by the creation mask alone).  The patch
> > also allows Samba to preserve any permission bits that the user hasn't
> > directly modified.
> >

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.

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".

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.
--------------------------------------------------------