[ClusterLabs] Antw: Re: Pacemaker detail log directory permissions

[Ulrich Windl]

>>> 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.
Wouldn't it be much easier to use some socket-bases syslog like service that
serializes all the message sto one file. Then the clients just need write
access to the socket, not to 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 message sbeing created
within a few minutes. Most GUI clients behave very badly once you hacve that
many messages.... But that's a different story in the subject...

> 
> 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...

> 
> 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).

> 
> 
> [*] 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)