SP packaging

[Ferenc Wágner]

"Cantor, Scott" <cantor.2 at osu.edu> writes:

> On 1/30/16, 10:25 AM, "Ferenc Wagner,,, on behalf of Ferenc Wágner" <wferi at niif.hu> wrote:
>
>> Probably because this function is not present in shibd: the uid change
>> is happening in the init script or in systemd, before shibd itself is
>> started.
>
> That's true, but the parameters to do it exist, they just aren't used
> right now anymore in the various init scripts. In fact, it may not
> actually be a bug, just user error not specifying the -u or -g
> parameters when using it.

Ah, right, I totally missed that these parameters exist since 2.5.0.
I'll have to update our man page as well.  I think you can argue that
running shibd -t as root without -u and -g is user error, still this
isn't particulary user friendly, as the description of the -t option is
'config test', so users don't expect filesystem modification.  What
about making this so by skipping cache writes when -t is in effect?
Shot in the dark: can't you omit caching the same way as
SPConfig::Logging?

BTW aren't you interested in taking the man pages created by Russ into
your tree, making them official?

>>> I don't know if I know how to fix the startup thing under systemd,
>>> but I can take a look, or you can tell me how. A new issue is fine.
>>
>> Well, there is ExecStartPre, which could serve as a workaround until
>> shibd can change uid on its own (if that takes long).
>
> shibd already can, but I was told pretty explicitly by people not to
> do it in things like systemd that already have a way to manage it.

Well, since shibd drops privileges upfront (it does not bind to
privileged ports, reads up protected config files or writes the PID file
beforehand), it has little reason to have its own privilege-dropping
code.  That's just more ground for (security) bugs.  Incidentally, looks
like the current code does not reset the list of supplementary group
IDs, lacking the initgroups()/setgroup() call.  On the other hand, using
su or sudo on the command line can provide the very same functionality.
Actually, writing the PID file and creating the listening socket as root
would allow dropping the /var/run/shibboleth subdirectory, but they
probably aren't worth the hassle.

>> By the way, do you plan to add socket activation support?
>
> No, it's very difficult for me to see how I could do it given the
> design and I don't see the benefit. The sockets are managed with an
> abstraction that's run deep inside the library, it's not anywhere near
> the "surface" of the daemon code.

That isn't necessarily a problem.  I'll occasionally take a look and
report back if you don't mind.
-- 
Regards,
Feri.