[ClusterLabs] Pacemaker detail log directory permissions

[Jan Pokorný]

On 29/04/19 08:20 +0200, Ulrich Windl wrote:
>>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 25.04.2019 um 18:49
>>>> in Nachricht <20190425164946.GF23995 at redhat.com>:
>> On 24/04/19 09:32 ‑0500, Ken Gaillot wrote:
>>> On Wed, 2019‑04‑24 at 16:08 +0200, wferi at niif.hu wrote:
>>>> Make install creates /var/log/pacemaker with mode 0770, owned by
>>>> hacluster:haclient.  However, if I create the directory as root:root
>>>> instead, pacemaker.log appears as hacluster:haclient all the
>>>> same.  What breaks in this setup besides log rotation (which can be
>>>> fixed by removing the su directive)?  Why is it a good idea to let
>>>> the haclient group write the logs?
>>> 
>>> Cluster administrators are added to the haclient group. It's a
>>> minor use case, but the group write permission allows such users
>>> to run commands that log to the detail log. An example would be
>>> running "crm_resource ‑‑force‑start" for a resource agent that
>>> writes debug information to the log.
>> 
>> I think the prime and foremost use case is that half of the actual
>> pacemaker daemons run as hacluster:haclient themselves, and it's
>> preferred for them to be not completely muted about what they do,
>> correct? :‑)
> 
> I interesting aspect: So the commands write directly to one file
> concurrently?  How's synchronization done. It's especially
> interesting with multiple threads.

You don't believe your libc (fprintf in particular) to abide the
POSIX constraints, do you? :-)

>   All functions that reference (FILE *) objects, except those with
>   names ending in _unlocked, shall behave as if they use flockfile()
>   and funlockfile() internally to obtain ownership of these (FILE *)
>   objects.

[https://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html]

> Wouldn't it be much easier to use some socket-bases syslog like
> service that serializes all the messages to one file. Then the
> clients just need write access to the socket, not to the files.

Two things:

- pacemaker _already_ uses the syslog interface (in daemon context,
  anyway; it can disabled, but I think there should at the very
  least be a toggle to optionally disable file-based logging
  altogether)

- it doesn't make the serialization problem any better
  (yes, it could perform some sort of buffered time-stamp based
  reordering on-the-fly, but that wouldn't make the situation any
  better than an explicit post-processing on the files)

>> Indeed, users can configure whatever log routing they desire
>> (I was actually toying with an idea to make it a lot more flexible,
>> log‑per‑type‑of‑daemon and perhaps even distinguished by PID,
>> configurable log formats since currently it's arguably a heavy
>> overkill to keep the hostname stated repeatedly over and over
>> without actually bothering to recheck it from time to time, etc.).
> 
> Reminds me of a project I had started more than 10 years ago: I
> wanted to start with a log mechanism, but the idea was rejected.
> At some later time out local mail system was brought to a halt
> by >300000 mail messages being created within a few minutes. Most
> GUI clients behave very badly once you have that many messages....
> But that's a different story in the subject...

Agree in a sense that explicit message spooling is not a substitute
for proper logging (as opposed to true alerts etc., but you can
usually configure mechanisms so as to forward very _select_ subset
of log messages like that in the syslog daemon of your choice).

>> Also note, relying on almighty root privileges (like with the
>> pristine deployment) is a silent misconception that cannot be taken
>> for fully granted, so again arguably, even the root daemons should
>> take a haclient group's coat on top of their own just in case [*].
> 
> See above.
> 
>> 
>>> If ACLs are not in use, such users already have full read/write
>>> access to the CIB, so being able to read and write the log is not an
>>> additional concern.
>>> 
>>> With ACLs, I could see wanting to change the permissions, and that idea
>>> has come up already. One approach might be to add a PCMK_log_mode
>>> option that would default to 0660, and users could make it more strict
>>> if desired.
> 
> With 0660 you actually mean "ug+w" (why care about read
> permissions)? Octal absolute modes are obsolet for at least
> 20 years...

Note sure about this opinion :-)
Luckily, chmod(1) still documents both.

>> It looks reasonable to prevent read‑backs by anyone but root, that
>> could be applied without any further toggles, assuming the pacemaker
>> code won't flip once purposefully allowed read bits for group back
>> automatically and unconditionally.
> 
> See above. "gu+w" could actually be "a-x,ug+w,o-rw" (which ist still
> different from 0660).

Generally, I read it you seem to agree with the idea of mode
updates as opposed to hard-coded modes, at least when it comes
to run-time enforcement (there are more subtopics in parallel).

>> 
>> 
>> [*] for instance when SELinux hits hard (which is currently not the
>>     case for Fedora/EL family), even though the executor(s) would need
>>     to be exempted if process inheritance taints the tree once forever:
>>     https://danwalsh.livejournal.com/69478.html 

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190429/519c7aa4/attachment.sig>