On 29/04/19 08:20 +0200, Ulrich Windl wrote: >>>> Jan Pokorný <jpoko...@redhat.com> schrieb am 25.04.2019 um 18:49 >>>> in Nachricht <20190425164946.gf23...@redhat.com>: >> On 24/04/19 09:32 ‑0500, Ken Gaillot wrote: >>> On Wed, 2019‑04‑24 at 16:08 +0200, wf...@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)
pgpZ6fFzStvFj.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/