shibd as non-root

[Russ Allbery]

"Scott Cantor" <cantor.2 at osu.edu> writes:
> Russ Allbery wrote on 2009-05-22:

>> Is there any way that we can check at startup time whether the _shibd
>> user can read the private key?  Some sort of shibd sanity check
>> option would be great here.  Then, we could modify the init script to
>> change users iff the sanity check passed and document in NEWS.Debian
>> that people should change the permissions on the private key so that
>> _shibd can read it.
>
> The problem is the configuration test process doesn't signal fatal
> errors every time something's wrong, it relies on manual examination
> for spotting problems. I'd have to think about it, but it's extremely
> non-trivial, there are too many pluggable components to control that
> kind of thing from outside.
>
> But if you're talking about *installation* time changes here, the only
> private key possible is the one it generates during installation,
> which has a known location and name.

The problem for us is upgrades from older versions of the Debian
package, where people may have changed shibboleth.xml to point shibd at
an entirely different key which is only readable by root.  We don't want
the upgrade to break their setup.

>> We should probably put _shibd in the ssl-cert group so that this will
>> just work for people who are using the standard Debian SSL key
>> layout.

> SSL credentials have no relationship to the ones used by the SP. I
> know Red Hat has been pushing an /etc/pki tree, but if anything it
> would end up being something like /etc/pki/<package> in that
> particular case.

That's basically what /etc/ssl is on Debian.  It's where you generally
put all X.509 certificates and private keys, regardless of what you're
going to use them for.  There are existing privilege setups, hashed
X.509 roots, and tools for doing useful things with keys and
certificates stored in that directory.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>