inherit mode

[Andy Bakun]

David Lee wrote:

> So instead of "inherit mode" being a simple boolean, perhaps it could
> be a multi-valued switch: no/yes/setgid:
> o  "no" (default) would maintain existing behaviour;
> o  "yes" would give my simple-to-explain per-share action;
> o  "setgid" would give Allison/Bakun "only applies to setgid".

I don't know if I should be associated with the setgid style opton.  That was not how
I understood Jeremy's to work, but thanks for clearing it up.  I also like the three
options idea, because you can then get that fine grained control if you want it.

> Although our user base is large, the majority of users want easily
> understood behaviour.  The majority will not even be aware of UNIX in the
> background, let alone the subtle intricacies of "setgid".

Most of my users are not even aware of NT Workstation in the foreground, let alone
the subtle intracacies of the "auto hide taskbar".

It now goes without saying that my users don't/can't login to UNIX, so I won't say
it.  This also means I don't need to explain "setgid" to them. :)

> Example: we set them a private home directory 711 (not 700: see below).
> Within that we (not they) pre-create a 755 "public_html" directory for
> their WWW space. Everything they create is private (files 600, subdirs
> 711) except within "public_html" (files 644, subdirs 755).

This is a fine example.  Traditionally my experience with samba is that the deeper
the directory tree gets, the only viable permission change is towards "more
restrictive" because of the interaction between samba forcing/masking modes and UNIX
permissions; this changes that.

> In the remaining minority (slightly more UNIX-aware), they will usually be
> satified with a one-off setting of 750 and 755 for group- and world-
> readable directories within the share, inheriting everything created in
> them.

I think this is important.  In UNIX, in order to share files with other users, you
always have to be aware of your umask, or at least willing to check/change perms
after creating a file.  On a file server, which is susposed to make sharing files
easier, users shouldn't have to worry about that, and thusly it would be nice if both
group ownership and permissions were inherieted on a directory by directory basis.
Here is an example from my network, and how it would change after the existance of
this option:

There is a share that contains all jobs, and there is a directory for each job that
is worked on, and in each "job directory" there is a certain standard set of
subdirectories.

job\report  (everyone can read/write)
job\notes  (everyone can read/write)
job\notes\private  (only readable/writable by certain people)
job\images  (everyone can read/write)
job\images\photos  (everyone can read, but only certain people can write)

I have force create mode set to 770 and force directory mode to 775.  Then, each
directory also has a group in /etc/group containing those people who can access that
directory.  Because job\notes\private uses the same "share parameters" as job\report,
I can't set the force create mode to 775 or 777 for job\report, because then people
can access job\notes\private.  It took us about 3 months to get this perfected.  It's
actually slightly more complicated (and there more directories) than I've described.

With "inherit mode = no", nothing changes (that is the default, right?)
With "inherit mode = yes", I can get rid of maintaining the groups for job\report,
job\notes and job\images, and just set those dirs to be 777 (thereby, all files in
the dirs inherit 777), and set job\notes\private and job\images\photos to be 770 and
775 respectively.
With "inherit mode = setgid", it's essentially the same, but I can set force mode to
777, only worry about permissions on the directories that require restrictive access
and set their permissions and the setgid bit on them.  The other directories, I don't
need to be concerned about their permissions or group ownership (other than to make
them globally writable to begin with)

Although, how force mode interacts with inherit mode is another story.  I think
technically Jeremy is correct in saying that force mode overrides inherit mode (after
all, that's what "force" means), but in practice, I think that using force mode and
"inherit mode = yes" should be undefined (or, one or the other should be ignored and
generate a warning in the log), and that "inherit mode = setgid" overrides the value
given to force mode.  This makes force mode work on files not within setgid
directories -- which I think is the most flexible behavior.

Also, people can get to the above described "job directories" via two methods.  Some
people have access to ALL job directories (\\server\jobsall), others only see the
ones they are working on (\\server\jobs) (a directory in their home directory,
%H\Jobs, is populated with symlinks to each job directory they should see).  This
means I need to verify permissions on three shares (\\server\USERNAME,
\\server\jobsall, and \\server\jobs) and three sets of directories (their home
directory, jobsall, and ~USERNAME/Jobs).  Using inherit mode = setgid, I only need to
maintain one or two sets of permissions, not six.  I can essentially forget about how
force mode interacts with the complex directory and group structure, and only
concentrate on the directories that need restrictive access.  Much simpler.

> I would put in a strong plea for keeping my original, simple, suggestion
> available, but would be happy for it to be modified to include a third
> option "setgid" as outlined above.

I agree.

Overall, I think inherit mode is close to The Right Thing(tm).  I know there has been
some debate in the past about having Samba implement it's own permissions structure,
and I think inherit mode allows samba to operate much more smoothly with UNIX
semantics than was possible before.

On another slightly related note, what about a parameter that changes the ownership
of moved files so they have the same group as the destination directory if the setgid
bit is set?  Moving a file in UNIX into a setgid directory doesn't change it's group
ownership, which makes sense from a command line security standpoint.  But when users
need to rearrange files in the directory structure I described above, which they
sometimes need to do, they need to call me so I can run the monster script I wrote
that fixes permissions in the job subdirs. I guess the way around this is to always
copy the file, then delete the source file, but like I said, most of my users are not
even aware of NT Workstation in the foreground, so this is hardly an acceptable
solution.

Andy.