We recently migrated a client from a peer-to-peer non-dedicated windows2000 "server" to a dedicated RedHat 9 Enterprise file server. We've basically kept the same layout with regards to file locations, but I'm trying to make sure that we're setting the permissions and ownership properly:

/home/company
This company folder and all subfolders/files have been set with "root" as the owner, and a group called "company". Permissions are 770. This is where files go that everyone needs to be able to see/work on.


/home/dianne
/home/jo
etc.


These are each user's individual or "private' folder. Each folder/file has been set with the user as the owner AND group. Permissions are 700

/home/clientapps

This is where software installation files are placed for the workstations, to make installing software convenient without the need to carry/find/use CDs. Owner is "root", group is "company". Permissions are 750.

For all existing files/data, this has worked well. The users can log in with proper username and password on their Windows machines, and with the same users and pw's set up in Samba, they are able to use their individual folders and the company folder, without seeing the contents of each other's "private" folders. All files/folders appear to open and save properly for each user.

My questions:

1. All the existing file/folder attributes were set after the migration using chown -R and chmod -R. But what about new files/folders created by the users? For example, user "dianne" places a file in "company". I assume the owner will be "dianne", but what will the group be? Will it be "company", just like the root folder, so that everyone can still use the file?

2. If a user places a file in their own "private" directory, but later moves it to the "company" folder, will others actually be able to use the file? Will it pick up the new permissions/group ownership of the destination folder?

3. Is there any harm in not granting "other" any permissions at all?

The goal, of course, is to have users be able to place files and/or folders in the appropriate directories and still have the "rules" established above remain in effect... without them having to know how to set file/folder permissions themselves.

I welcome your answers as well as any suggestions you might have regarding the permissions/ownership structure I've specified here.

1. If you want everyone to read/write/execute to the ~/company folder set it as 777

3. What do you mean by "other"?

by "others" I mean the last digit of the permissions number. For example, "770" is owner rwx, group rwx, others ---

What exactly "others" is, I don't really know, that's why I asked. I assume it's all other users that are not the file owner or member of the file group. Another way to ask the question... if you right-click on a file in GNOME, select properties, and click the permissions tab, you'll see the ability to set rwx for Owner, Group, and Others. Why, when setting permissions for this particular type of setup, would I not want "others" to have ZERO access... I'm trying to control access in the Company folder so that there's full access for JUST the file owner or members of the "company" group... no "others".

I ran a test. If user "cynthia" places a file in the company folder, under our current configuration, it's saved with the following attributes:

file owner: cynthia
file group: cynthia
permissions 744

None of which line up with the company folder's intended use:

file owner: whomever places the file in the directory
file group: "company" (a group of which all users are a member"
permissions 770 (owner and group members can do whatever they want with the file, "others" can do nothing)

In other words, if Cynthia places a file in the company folder, other "company" group members can READ the file, but if they open it, change it, then try to save it, they are prompted for a new file name because for them, it's "read only". (Interestingly, they can DELETE it though).

Not the desired effect, which is:

Cynthia places a file in company folder.
-- She is the owner of the file. She should have rwx to the file
-- Members of the "company" user group should also have rwx to the file. The "file group" should be "company".
-- Others that are not logged in, or those that are not the file owner or a member of the "company" user group should not be able to do anything with the file.

So far, it's only because of the samba permissions and the regular file system permissions on the company folder itself that I can limit access to the files. But when users place the files there... its like I said... the file owner/group and permissions on the file are not conducive to full sharing/manipulation of the file by authorized users.

I'm not afraid to edit the samba config file directly, I just don't know how to set up this company share so that it's properly secured.

Thanks for your post!! I do very much appreciate the help. I'm still such a noob...

You can set the SGID bit on the /home/company folder (chmod 2770) to force new files created in that directory to have their group ownership be company. As for making them group readable, writeable, and executable, you'll need to set the umask of each of the users not to dent group permissions to each file, Man umask will help you, but note that the second digit of the umask must be 0.

I actually figured out the Group ID bit just as your message came to my inbox... glad to see I was on the right track.

As far as umask, if I enter "man umask" I get a whole PILE of stuff... is there a place I can look for compresensive information about the umask command? Event the LQ glossary seems a little short on examples, etc.

Thanks!

m

The following combination of changes seems to have yielded the results I was looking for:

1. Setting the "set group id" to ON for the top level "company" directory (ensures that while the file's OWNER remains the same, based on who created the file, the file's GROUP is always changed to the "company" group, when created, just like the top level directory).

2. Adding the following lines in SMB.CONF for the 'company' directory share:

Anybody see any problems with this? Why is everyone else's solutions so much more complicated (i.e. umask, folder watching/permissions changes based on CRON, etc.)? Am I missing something (probably!) ?

I imagine those SAMBA directives would work (I'm not a SAMBA expert, though). The other suggestions, though, would help if users ever access the files through some other method e.g. SSHing to the server or via NFS to a remote *nix host.

ah yes, I get it.... since these are SAMBA attributes only, file/directory creation via other means would not have those same attributes applied.

I'm still having a problem with new directories not getting the proper attributes set... still working on it...

Final Solution to my inquiry:

1. Setting the "set group id" to ON for the top level "company" directory (ensures that while the file's OWNER remains the same, based on who created the file, the file's GROUP is always changed to the "company" group, when created, just like the top level directory). Make sure top level "company" directory has the desired permissions to prevent non-user/group members from accessing the directory contents. (In other words, file owner = root, set file group = "company" group, and set directory permissions at 2770).

2. Edit the "company" share in the SAMBA config file:

Note that this solution ONLY applies to SAMBA shares. Files/folders created in the Company service via any other means will NOT have the permissions modifications automatically applied to them.

Bottom line:

This setup allows Windows users that are a member of the Linux user group "company" to create folders and subfolders in the "company" SAMBA share. It allows other Windows users to modify or delete those folders and subfolders. The original creator of the objects is retained in each object's "file owner" attribute. Users that are not a member of the Linux user group "company" are not permitted access to the root of the "company" SAMBA share or any of it's contents.

To anyone reading this: If you discover a hole in the setup, or have a better way... post back here so that other noob's such as myself can learn from this and also set up a secure means of setting up SAMBA shared folders for their windows users.

I also welcome any additional comments that would force the same "rules" when accessing/using the shared directory from "outside" SAMBA.

I followed what you did and tried some other stuff. I found the following worked best for me as I don't want to allow the 'Everyone' group in Windows to have any access.

Seems when create a file, the others in linux get read access. This is due to the umask in /etc/profiles of 022.

Here is how I set up my Company share in smb.conf:

[Company]
directory mode = 770
comment = Public Directory
force directory mode = 770
force create mode = 770
create mode = 770
path = /home/company
force group = company
valid users = @company
writable = yes

Some redundancy with the create mode, but I don't think it hurts anything.

Also did "chmod 770 /home/company" . Now whenever someone creates a file in the company folder it's owner:group is username:company and the perms are -rwxrwx---. Just what I wanted.

Thanks !


I think setting the umask to 0007 in /etc/profile will do the same for other than Samba file creation. This setting is system wide so problably better to add to each user's shell profile or create some 'if-then' logic in the /etc/profile to set umask for only users with UID > 500 or whatever you have them as. Assuming all your new user accounts were created starting with UID 500.