Usual directory for Shib SP 2.5.x for local backing copy of metadata?

[Cantor, Scott]

On 3/21/13 12:27 AM, "Michael A Grady" <mgrady at unicon.net> wrote:

>So the Shib 2.5 SP installs mostly ready to be run as a non-root user
>(shibd), and changes a number of file permissions to do so. But it leaves
>/etc/shibboleth as owned by root:root, and that seemed to be a pretty
>standard place for the file-backed copy of federation metadata to go.

If you mean a locally maintained metadata file, yes, /etc/shibboleth would
be the default. And that would normally be owned by root.

If you mean the backup copy of remotely loaded files, the default has
never been /etc. It was (wrongly) /var/run/shibboleth until 2.5 when it
was corrected to be /var/cache/shibboleth, since /var/cache survives
reboots. Those are owned by shibd.

The default locations have always been the ones that are automatically
resolved when filenames are used by themselves in settings, and that's
almost always the correct thing to do. The log always records the full
path being used for something.

> Are you changing permissions on  that directory manually, or now writing
>(maybe you always did?) the local copy of the federation metadata into an
>alternate directory? One of the Shibboleth-specific /var directories that
>get created and are owned by shibd?

The /var directories have always been the default location for any files
created at runtime; that's never meant to be /etc/shibboleth and it's
never done any writing to that location that I can ever remember. If
people make changes to do things that are against Red Hat conventions,
then they are owning those changes and can't rely on packages to do the
right thing. RPMs are mostly a lot of conventions that have to be followed
or bad things will happen, some of which I've violated at times and been
yelled at for it.

That said, were it up to me I would not have changed it from root. There
is no way to avoid breaking *some* systems doing that in an RPM upgrade,
and so I called out that change loudly in the wiki. Enough people were
breaking their own systems by modifying init scripts to use non-root that
it was a choice between breaking one group or another.

-- Scott