One file wants to belong to two users. How? Hard linking fails

Two setuid programs, /usr/bin/bar and /usr/bin/baz, share a single configuration file foo. The configuration file’s mode is 0640, for it holds sensitive information. The one program runs as bar:bar (that is, as user bar, group bar); the other as baz:baz. Changing users is not an option, and even changing groups would not be preferable.

I wish to hard link the single configuration file as /etc/bar/foo and /etc/baz/foo. However, this fails because the file must, as far as I know, belong either to root:bar or to root:baz.

Potential solution: Create a new group barbaz whose members are bar and baz. Let foo belong to root:barbaz.

That looks like a pretty heavy-handed solution to me. Is there no neater, simpler way to share the configuration file foo between the two programs?

For now, I am maintaining two, identical copies of the file. This works, but is obviously wrong. What would be right?

For information: I have little experience with Unix groups and none with setgid(2).

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

You can use ACLs so the file can be read by people in both groups.

chgrp bar file
chmod 640 file
setfacl -m g:baz:r-- file

Now both bar and baz groups can read the file.

For example, here’s a file owned by bin:bin with mode 640.

$ ls -l foo
-rw-r-----+ 1 bin bin 5 Aug 17 12:19 foo

The + means there’s an ACL set, so let’s take a look at it.

$ getfacl foo
# file: foo
# owner: bin
# group: bin
user::rw-
group::r--
group:sweh:r--
mask::r--
other::---

We can see the line group:sweh:r-- : that means people in the group sweh can read it.

Hey, that’s me!

$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh)

And yes, I can read the file.

$ cat foo
data

Method 2

You may want to reconsider these statements:

Potential solution: Create a new group barbaz whose members are bar and baz. Let foo belong to root:barbaz.

That looks like a pretty heavy-handed solution to me. Is there no neater, simpler way to share the configuration file foo between the two programs?

Why is it heavy-handed to create a new group? Doing so has the following advantages over ACLs:

• Although you have phrased this as a hypothetical with commands /usr/bin/bar and /usr/bin/baz, it’s relevant that these two programs can share a configuration file. This suggests that the programs are naturally related. Creating a new group for them would seem to describe a relationship that actually exists and should trigger behavior (such as permissions to read the common configuration file).
• Solving this problem via groups is portable to every Unix, meaning that you can rely on the same mechanism, working exactly the same way, on any Unix or Unix-like system. ACLs are far more complex and portability can be a problem.

Personally I see ACLs as the heavy-handed solution here, and groups as the simpler, traditional Unix way.

Method 3

I would think this would be a typical use for Access Control Lists (ACLs). Add both users (or groups) to the config-file’s ACL:

/etc/foo  root:root rw-------  # Traditional Unix ownership and permission for foo

$ setfacl -m user:bar:rw- /etc/foo  # Allows user bar to read and write foo
$ setfacl -m user:baz:rw- /etc/foo  # Allows also user baz to read and write foo

You may have to install the acl-package first.

Method 4

Make the file’s mode 0660 (or even 0440 if writing is not required) and ownership bar:baz. Then one process can access the file thanks to user permissions, the other thanks to group permissions. This works even on file systems where ACLs don’t.

Method 5

I’ll submit this since it’s not yet mentioned. Even though this is probably not what you want, it may be the answer for other people with a similar question.

The “new” “cloud” way is to have all configuration handled by a configuration management system (such as chef, puppet, or ansible). It does not then matter that you have two distinct but identical files on the server, since both are a copy of the single file from the configuration management system.

The main advantages of doing it like this is that your configuration is versioned (along with all the rest of your configurations), and that deploying a new identical or almost-identical server becomes so easy that ot can be automated.

(For the record, since you are not using configuration management, I would go with the group system as in @drg’s answer).

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0