current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 13 down vote favorite
2

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).

share|improve this question
    
The question is generally phased. In my specific case, the two programs happen to be Exim4 and Dovecot, mail-handling programs that can share passwords and TLS certificates. – thb 15 hours ago
3  
the Ubuntu (& I think Debian) solution for this is the ssl-cert group, which is pretty much your barbaz group. The standard is to set all private keys to be owned by the ssl-cert group, and put the UIDs associated with the programs that need to access them into that group. – abligh 11 hours ago
1  
@abligh: Interesting. My system is Debian 8 jessie. Apparently, there exists a package ssl-cert whose postinst script, at installation, creates the group of which you speak. I had been unaware of ssl-cert. Apache2 (installed on my host) recommends ssl-cert. The various Exim and Dovecot packages do not, but Postfix (not installed on my host) depends on ssl-cert. Due to Apache, my host does have an ssl-cert group, but this group has no members yet. Thanks for the advice. – thb 10 hours ago
2  
Make the programs setgid, not setuid. Setuid programs are a bad idea because if they're compromised, the binary can be replaced, creating a trojan horse. (Exception: setuid root, because there you don't have a choice.) – Gilles 10 hours ago
    
Does wiki.dovecot.org/HowTo/EximAndDovecotSASL solve your specific situation? – MvG 1 hour ago
up vote 21 down vote accepted

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, set let's 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
share|improve this answer
up vote 10 down vote

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.

share|improve this answer
up vote 4 down vote

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.

share|improve this answer
    
I see now that some of this was addressed in the comments to your question. I decided to submit this answer anyway because it's not already represented in the existing answers. – drg 4 hours ago
up vote 1 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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