Samba/Filesystem Permissions Help

Ben Scott dragonhawk at gmail.com
Tue Oct 2 15:54:14 EDT 2007


On 10/2/07, Matt Snell <mattds at gmail.com> wrote:
> Assume that the user "matt" is in "smbusers" on the server and has a valid
> Linux and Samba username/password set.

  Just to clarify: Here, you refer to a Unix group (in the /etc/group
file) called "smbusers", and not an entry in the /etc/samba/smbusers
file.  Yes?

> Directory Permissions: I've set the sgid bit on the dir so that the group is
> always set to "smbusers" and that group will always have rw access (suid/sgid
> is new to me, correct me if I'm wrong in my thinking).

  Pretty close.  The SGID bit on a directory will cause new entries
(files, subdirectories, named pipes, etc.) created under that
directory to inherit the group ownership of the directory.  Also,
subdirectories created under the directory will inherit the SGID bit.
However, SGID does not affect the mode (permissions) of new entries.
You still have to worry about umask and create mode.

  Also, I seem to recall discovering that Samba has some issue with
SGID directories.  I don't recall exactly what.  In any event, I long
ago adopted the habit of specifying the following (in smb.conf or
includes) for Samba shares intended to be accessed by multiple people:

[shared]
# ... stuff here ...
# file modes are user/group=R/W, world=NONE
create mask = 660
force create mode = 0660
# directory modes are SETGID, user/group=R/W/X, world=NONE
directory mask = 770
force directory mode = 2770

> The user "matt" exists on the client, there is no smbusers group (maybe there
> should be?).

  Well, that depends.  Are you using mount as a single-user thing or a
multi-user thing?  In other words, is user "matt" mounting xfer
somewhere for his own use, or are multiple people going to be using
that mount?

  If the former, the mount is essentially Matt's property, and so you
can just ignore all this SMB permissions crap.  A common scenario is
that each user is mounting SMB shares under their home directory
(e.g., "mount -t smbfs //server/share $HOME/corp").  Each user
manually does their mounts and punches in their individual passwords
when prompted.  The SMB server sees them as just-a-user accessing
files.  On the SMB client, all access through that mount is done as
and on behalf of Matt.  It's up to Matt to protect the mount, as with
any other thing in Matt's home directory.  In this scenario, "noperm"
is perfectly acceptable from a security standpoint (it might be
annoying in that the execute bit gets clobbered, but that's not
security-relevant).

  In the later scenario, the sysadmin of a multi-user system is
mounting a share for multiple users on that system.  The sysadmin uses
separate credentials to set-up the mount.  For example, "mount -t
smbfs -o username=linuxbox //server/share /mnt/corp".  Then multiple
users of the SMB client can access files under /mnt/tmp, with the
proper permissions and ownership, enforced by and on the SMB client.
In this case, you need the SMB to propagate the Unix file ownership
and mode.

  Personally, I never had much luck using SMB from Unix-to-Unix.  NFS
worked better (scary as that thought is).  However, the last I tried
was about seven years ago.  I know other parts of Samba have changed
radically since then, so maybe SMB works better now, too.  Perhaps
someone else with recent experience can speak on this aspect.

  Anyhow, if you *do* want to do the multi-user SMB thing, you're
right in that you need a way to replicate the Unix user and group
information across the various systems.  This is, to the best of my
knowledge, not something SMB does itself.

  You're right in that it can be done manually.  Just create users and
groups with the name numbers and names on all the systems.  You're
also right in that doing it manually stinks.  I recommend against this
unless you only have a handful of hosts and a handful of users, and
even then it still stinks.  But so does everything else.

  The traditional Unix way of doing this was with NIS (Network
Information Services, AKA "Sun Yellow Pages").  This is not actually
overly hard to set-up, once you know what to do, but it is incredibly
poorly documented and idiosyncratic.  Can anyone else on this list
suggest a HOWTO document that is up-to-date, accurate for Linux, and
coherent?

  The new-fangled way is by using LDAP.  I know nothing about how to
do this.  I'm betting it stinks.

-- Ben


More information about the gnhlug-discuss mailing list