Workaround for files/folders owned by a dynamic UID/GID #90
Labels
No labels
docs
kind
bug
kind
enhancement
kind
package-request
release
f40
release
f41
release
f42
release
f43
release
f44
release
f45
release/rawhide
upstream
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
atomic-desktops/tracker#90
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As long as we are still using
nss-altfiles, we will have issues with dynamically allocated UIDs/GIDs from RPMs that install files in/var&/etcwith those UIDs/GIDs.Workaround that by selectively resetting the UID/GID for some folders in
/var/&/etc.Long term fix is: https://github.com/coreos/fedora-coreos-tracker/issues/1599
See:
set status to To do
https://pagure.io/workstation-ostree-config/pull-request/706
mentioned in issue #81
mentioned in commit ci-test@622dbff756d6c5284b8dd579f0ec1066d0583af1
mentioned in commit ci-test@b56b54f6369776f436bcd422155cef0c4e47e58e
mentioned in commit ci-test@795036707038ac042452f1253f6fbec52654be34
Sorry to jump in here but I'm not sure exactly where to report. There's an rpm-ostree fedora user who reports similar UID change issues with the freshclam package, but the issue has been lingering for a while against libvirt package: https://bugzilla.redhat.com/show_bug.cgi?id=1988740
Where should I ask them to follow up to get their issue resolved? Thanks in advance
Right now it should be directed to the freshclam package to use either systemd features to set ownership on directories or tmpfiles config to do the same like: https://pagure.io/workstation-ostree-config/pull-request/706
changed the description
mentioned in commit ci-test@052faae202c017c6d1c8ed0daef15dac54eede6b
Workarounds in:
mentioned in commit ci-test@ca271955b1d1d4a58b7249f527fb7c6e00f70790
mentioned in commit ci-test@e3c32ef75686b611202da919d3c7265d3b28b492
set status to In progress
Proper fix for this issue is tracked in #108