On 10/2/07, Matt Snell <[EMAIL PROTECTED]> 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 _______________________________________________ gnhlug-discuss mailing list [email protected] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
