-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shadow files are user readable #4401
Labels
Comments
Ultimately what we want I think is for the shadow files to not exist in the ostree commit at all. Instead we should generate them on first boot if they don't exist. This may require OS level work. |
cgwalters
changed the title
shadow files are user readeable
shadow files are user readable
May 18, 2023
We could have rpm-ostree generate them when missing when 'unpacking' a commit |
this triggers SELinux
|
cgwalters
added
priority/medium
difficulty/medium
medium complexity/difficutly issue
labels
May 31, 2023
travier
pushed a commit
to travier/rpm-ostree
that referenced
this issue
Apr 9, 2024
Because of how our composes work, we need to manually inject passwd-related things before installing packages. A somewhat recent regression in that area made it so that the `/etc/shadow` and `/etc/gshadow` files were created with default permissions (0644), which meant they were world readable. Fix this by explicitly setting their modes to 0. Ideally, we would rely on the canonical permissions set in the `setup` package here, but it's tricky to fix that without reworking how we install `setup` and handle `passwd` treefile options. Fixes fdb879c ("passwd: sync `etc/{,g}shadow` according to `etc/{passwd,group}`"). Fixes coreos#4401
lukewarmtemp
pushed a commit
to lukewarmtemp/rpm-ostree
that referenced
this issue
Apr 15, 2024
Because of how our composes work, we need to manually inject passwd-related things before installing packages. A somewhat recent regression in that area made it so that the `/etc/shadow` and `/etc/gshadow` files were created with default permissions (0644), which meant they were world readable. Fix this by explicitly setting their modes to 0. Ideally, we would rely on the canonical permissions set in the `setup` package here, but it's tricky to fix that without reworking how we install `setup` and handle `passwd` treefile options. Fixes fdb879c ("passwd: sync `etc/{,g}shadow` according to `etc/{passwd,group}`"). Fixes coreos#4401
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Scanning my system using oscap / cis profile,
shadow files have incorrect permissions
Host system details
Alma 8.7 based OS
Expected vs actual behavior
Expected:
shadow files should have mode 0000
Steps to reproduce it
The shadow files in /usr/etc have mode 0400 on purpose 334f0b8
This seems to be a side effect
chmod 0000 /etc/*shadow*
doesn't break my systemMaybe we can fix it using tmpfile.d config
see also #1045
Would you like to work on the issue?
No
The text was updated successfully, but these errors were encountered: