[ClusterLabs] Pacemaker detail log directory permissions

[Jan Pokorný]

On 26/04/19 09:33 -0500, Ken Gaillot wrote:
> On Thu, 2019-04-25 at 18:49 +0200, Jan Pokorný wrote:
>> 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? :-)
> 
> The logs are owned by hacluster user, so the daemons don't have an
> issue.

Well, the it's not the particular file that's in question, but rather
the directory in the traversal path to them.  It can indeed create
problems with 0770 mode for it while not owned with those particular
non-root credentials (for non-root daemons or similarly, with the
current ownership and root not having the DAC override permissions
for root daemons as mentioned), so potentially there's a catch with
the arrangement OP asks about, at least IIUIC.

>> 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.).
>> 
>> 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 [*].
>> 
>>> 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.
>> 
>> 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.
> 
> Pacemaker does indeed ensure the detail log has specific ownerships and
> permissions -- see crm_add_logfile().

Yes, and that'd intefere with my idea; it would explicitly need
_not_ to zero read bit for group once the possibly predestined default
of not allowing that was overridden by the admin.  Still more elegant
than yet another toggle -- file system level "configuration" is the
definite one without any need of intermediate levels just increasing
complexity.

-- 
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/20190426/8ce5252b/attachment.sig>