Should the package ship a world-readable config file?

[dkg]

The config file in /etc/sasl-xoauth2.conf is by default world-readable, but it contains (as a template):

{
  "client_id": "CLIENT_ID_GOES_HERE",
  "client_secret": "CLIENT_SECRET_GOES_HERE"
}

As a packager, it makes me a little bit worried that we're shipping something world-readable that says it contains a "secret". This is a configuration file that i'll want the package to maintain as the versions advance, but there are various problems with ensuring that the file is readable by the right parties (presumably postfix needs to read it, but binding it tightly to postfix makes it that much harder to use with some other toolchain in the future, if that ever happens), as well as problems with upgrading the shipped configuration file when the admin has manually modified it (this always makes package upgrades a chore).

A couple possible approaches to resolve this:

• don't ship the config file at all in the package -- instead, ship documentation that describes what the configfile is supposed to look like, and let the system administrator create it with the appropriate permissions for their own deployment.
• choose a particular user:group pairing, and ensure that during installation it's set to mode 640, so that members of that group can read it and no one else can.

If we go with the first option (which is my preference), i'd the documentation could be either a sasl-xoauth2.conf(5) manual page or an example config file (with some comments) someplace like /usr/share/doc/sasl-xoauth2/examples/sasl-xoauth2.conf. In either case, we'd want the documentation to clearly state:

• what parameters go in the config file, and how they're formatted
• where it is typically located, and
• what permissions on the file should look like

any preferences for how to solve this?

[tarickb]

I'm not entirely convinced it's a real problem to have the client secret stored in a world-readable file (see #57), but if we have to do something about this, I'd also prefer the first option. It's not like the file we're shipping now is in any way useful -- it has to be modified anyway.

Unfortunately the config file is treated as JSON data so we don't really have a great way to annotate parameters and usage. I think (?) the best we can do is the template format we have today. Does this mean we'll have to go the sasl-xoauth2.conf(5) manual page route?

[dkg]

I'll go ahead and avoid shipping the config file directly in /etc/sasl-xoauth2.conf, and i'll ship a copy in /usr/share/doc/sasl-xoauth2/ - if you could create a sasl-xoauth2.conf(5) manpage, that would be great! I've offered #59 as one possible starting point, but i defer to you on the best way to generate/integrate this kind of thing.

[dkg]

btw, @rrthomas (a debian user) wrote to me:

I don't think I have particular insights here. I don't use /etc/sasl-xoauth2.conf, as postfix files have to go in a different location for postfix's /var/spool/postfix chroot (but yes, it should not be world-readable by default), and I simply don't use the command-line argument (but I agree it should probably be removed so as not to offer users a way to shoot themselves in the foot). I can't think of any reason why changing these would be particularly bad (removing the command-line option might annoy some users, but clearly in their own interests!).

[dkg]

I'll go ahead and avoid shipping the config file directly in /etc/sasl-xoauth2.conf, and i'll ship a copy in /usr/share/doc/sasl-xoauth2/

This is done with 0.19-2, in debian experimental now.

[tarickb]

I'm sorry this slipped off my radar for a while. @dkg -- anything left for us to do here?