-
Notifications
You must be signed in to change notification settings - Fork 266
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
set file and dir permissions #1922
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR should not be merged until discussion in #1921 will not be finished.
173cef8
to
f2a2bde
Compare
I support merging this and including it in the next 0.6.x release. Couple of weeks later, it should be followed by a PR going back to the more strict handling advocated by @cheatfate which should be our long-term policy. |
not sure this is meaningful any more - ie the damage is done already |
This is a new more minor change to the permissions (but still breaking). It removes the group-level access from the sensitive directories. |
f2a2bde
to
045f7b3
Compare
@zah couple of weeks already passed but there no new PR, so maybe i should open "security" issues because of that? |
Yes, I think it's time that we fix this. Perhaps it can be addressed in the not yet merged passwordless keystores branch? |
access()
function, since it doesn't do anything we need. https://man7.org/linux/man-pages/man2/access.2.html :In other words, access() does not answer the "can I read/write/execute this file?" question. It answers a slightly different question: "(assuming I'm a setuid binary) can the user who invoked me read/write/execute this file?", which gives set-user-ID programs the possibility to prevent malicious users from causing them to read files which users shouldn't be able to read.