2

I am configuring a Linux work station that will be used by a small number of users (20-30). These users will belong to a small set of groups (5-10) with each user belonging to at least one group and potentially multiple groups. On the work station there are files that should only be writeable by members of a particular group. Each file is only writeable by members of one group so standard Linux permissions should work just fine. I have two questions.

Who should own the files that already exist? I was thinking either root or creating a set of dummy users corresponding to the groups. Is there a better choice that I am missing? It seems like this is unlikely a unique situation so I was hoping there was a standard convention.

The second question is where should I put the files. If I made dummy users I could create subdirectories in /home/. If root owns the files do I go with /srv/groups/ or maybe `/share/? Again is there a convention?

3

Who should own the files that already exist? I was thinking either root or creating a set of dummy users corresponding to the groups.

Leaving them owned root but belonging to a common group, presuming the files are masked 0002 (i.e., are group writable) has a little bit of an advantage in terms of preventing them from becoming accidentally reowned if you create users to match the groups and the people who are in the groups can log in as that user. I'm referring to accident here because of course a malicous user in the group will just be able to delete the files in any case. But if they are owned root (or any other user that is not the group), then while someone in the group can still write to them (and thus delete them), they won't be able to reown or modify the permissions such that other members of the group won't be able to subsequently access the file.

Using a group but no fixed owner (i.e., files can be owned by anyone, but should be in the correct group with group permissions) has an advantage if users will be creating files (see below).

Creating new users just to match the groups will probably create more potential problems than it actually solves. If using group permissions works, stick with that. You can also create a little command for the superuser:

#!/bin/sh
chown -R root:groupx $1
chmod -R g+w $1

And use it foo /some/directory. This will ensure everything in the tree is owned root, with group groupx, and group writable.

There is a potential problem using root as the owner if root then adds the setuid bit to a file, but I believe only owner can do that. If you are really worried, create a dummy user -- but not one that matches the group. One that has no privileges but no one can use.

There is one further issue with users creating new files, which by default will be owned by them. They will be able to change it to the correct group, which will make the file accessible to others, but they won't be able to change the owner. For that reason, and because people may forget, you may want to run foo /some/directory at regular intervals or opportune moments (e.g. when no one is logged in, since changing the ownership may affect software which has the file open).

Taking the last paragraph into account, you could just say the owner does not matter at all, only the group is important. In that case the foo command should use:

chgrp -R groupx $1

instead of chown.

where should I put the files

Creating a /home/groupx is absolutely fine even if groupx is a group and not a user. The only potential issue would be if you then go and create a user with the same name -- but you don't want that anyway. Put the files there and foo /home/groupx.

If you don't want users to be able to create files, set the directory 755. They will still be able to modify files owned by their group.

1

Usually, in this situation, the files will be owned by whoever saved them last (or whoever created them, if they're being edited with a program that modifies the existing file rather than creating a new version). If you're creating a set of initial files, I would leave them owned by your account, unless you're seeding data for a group that you don't belong to, in which case root is as good as any. But it's no big deal.

There is no widely-held convention for data that is neither part of the system (/usr, /var, /bin, /sbin, /lib, /etc) nor users' home directories (/home). You can make other directories under /home, or you can put them elsewhere. /srv is in principle for data used by servers, but as the system administrator, you're free to put whatever you want there. /net/MACHINENAME is a popular choice for “miscellaneous data stored on MACHINENAME” on networks where machines export filesystems to each other.

  • @goldilocks Yeah, ok. Edited. – Gilles May 10 '14 at 13:08
  • "if they're being edited with a program that modifies the existing file rather than creating a new version" I would guess practically all software falls into the former category, since otherwise it would fail when working on a writable file in a directory without write permissions. I.e., files tend to remain owned by whoever created them, and modifying them should pretty much never affect that. – goldilocks May 10 '14 at 13:14
  • @goldilocks unix.stackexchange.com/questions/45407/… – Gilles May 10 '14 at 13:17
  • Okay -- but if the part of the strategy (create a new file when possible, otherwise modify) hinges on recreating the original ownership (this is what happens experientially) then the end result is the same: the file will remain owned by the original creator, and not the user editing it. I think software that does not follow that pattern (i.e., changes owners on write) would be eccentric. – goldilocks May 10 '14 at 13:29
  • @goldilocks Most unix variants do not allow giving away a file (only root can chown). Software that changes owner when saving a file is quite common. – Gilles May 10 '14 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.