https://bugzilla.redhat.com/show_bug.cgi?id=2088450 Jakub Ruzicka <jakub.ruzicka@xxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jakub.ruzicka@nic |needinfo?(pemensik@redhat.c |.cz) |om) --- Comment #13 from Jakub Ruzicka <jakub.ruzicka@xxxxxx> --- Upstream response: > What kind of access does root needs to other users' files? What does root need to do with those files? The root needs both read and write access because the SHM files are used just like standard files for better efficiency. In general, these files are used for all IPC and the root user is supposed to be the privileged one that has unlimited access and can communicate with all the other sysrepo clients (users). This has worked fine before until the aforementioned kernel parameter was introduced a year or two ago. > Would it be possible if the running service did such access on root's behalf, where it would already have the group in question? I do not understand, what exactly is "the running service"? This service must run with the root user, we have already agreed on that. > Is that requirement described somewhere in documentation? What exactly it creates in /dev/shm for root user and for unprivileged users? And in which cases it needs access from root user to files created by other users? Sounds like strange use-case. No, this requirement is not described anywhere in the documentation because it is a standard UNIX expectation of the root user having access to everything on the system. Generally speaking, all the SHM files can be accessed by all the sysrepo users because the permissions are checked manually by sysrepo. The special group is used mainly to enhance security by not allowing direct file tampering by other system users. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2088450 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
