>>> Jan Pokorný <[email protected]> schrieb am 25.04.2019 um 18:49 in Nachricht <[email protected]>: > 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? :‑)
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) _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
