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, [email protected] 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)
pgp_Z6tLz9aGY.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
