BUG with g+s: Re: "Inherit Permissions" request for comments

[Cole, Timothy D.]

[ warning: rambling thoughts ahead ]

I think what we're seeing here is really the conflict between two separate
userbases for Samba:

 1. those using Samba to provide Windows clients access to data on a Unix
system

 2. those using Samba to replace an NT system

I've been involved in enough discussions here to realize that the
requirements of the two groups are often contradictory, at best.

I'm starting to wonder if a "server mode" paramter in smb.conf might not be
appropriate, with one of two settings:

 server mode = native

  or

 server mode = windows

It would mainly only affect the default settings for a number of specific
options (e.g. inherit permissions and so forth).

With the exception of a few things like the bug (it is a bug) we're
discussing here, for the most part Samba currently displays 'server mode =
native' behavior, so that should of course be the default.

The defaults would of course be overridden by any explicit options in the
config file, as is usual.  It shouldn't be an excuse to just lump these
options together, of course; fine-grained control is important, but as a
rule people are probably going to want the options in chunks.

Maybe the existence of this distinction in Samba configuration would also
help people think twice when making modifications to improve one mode of
operation, so that they don't damage the other (as has happened here).

> -----Original Message-----
> From:	Michael Tokarev [SMTP:mjt at tls.msk.ru]
> Sent:	Monday, June 05, 2000 10:38
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: BUG with g+s: Re: "Inherit Permissions" request for
> comments
> 
> David Collier-Brown wrote:
> > 
> > Michael Tokarev wrote:
> > >                                 In the other words,
> > > inherit permissions parameter changed semantics of g+s when unset.
> > > If this is considered normal, than it should be documented as
> > > compatibility change (that is, 2.0.7 is incompatible with all previous
> > > versions on this respect).
> > 
> >         "Erk", saith the tech writer! (;-))
> > 
> >         Seriously, though, once we decide upon a resolution,
> >         I'll propose a migration strategy to this list and a
> >         documentation change to the docs list.
> 
> Just a thought -- this particular change:
> 
>   Cope with UNIXes that don't allow high order mode bits on mkdir.
>   Patch from gcarter at lanier.com.
> 
> Is it will be better to test if particular system does not support
> high order mode bits in mkdir with autoconf and do _not_ use chmod
> if it supports them?  It will improve things a bit...
> 
> But one more thing -- BSD semantics is a bit different than posix
> ones in g+s respect.  BSD, as I know of, always inherits group from
> parent dir, so g+s is simple unnecessary there (correct me if I'm
> wrong, I have no BSD around).  And with this (gid is inherited), would
> it be "better" to issue chgrp/chown call after creation of
> file/directory!?
> With current approach with chmod, seemed to be logical at least... :)
> Maybe samba will be another OS with it's own permissions, owners, groups
> etc and own rules on all this, owerriding underlying OS's (good) work??!
> This all is like an argument for my previous message. :)
> 
> While on unix, I never have a trouble with setting file
> permissions/groups/etc.
> Why the samba "layer" introduces new things that can be avoided on
> plain unix?  Is is will be better to just implement chmod/chgrp/chetc
> ability (using maybe NT's ACL dialogs or something on samba's own way)?
> 
> Regards,
>   Michael.