Skip to content
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

Merged
merged 1 commit into from
Nov 17, 2020
Merged

set file and dir permissions #1922

merged 1 commit into from
Nov 17, 2020

Conversation

stefantalpalaru
Copy link
Contributor

@stefantalpalaru stefantalpalaru commented Oct 30, 2020

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.

Copy link
Contributor

@cheatfate cheatfate left a 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.

@zah
Copy link
Contributor

zah commented Nov 13, 2020

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.

@arnetheduck
Copy link
Member

not sure this is meaningful any more - ie the damage is done already

@zah
Copy link
Contributor

zah commented Nov 14, 2020

This is a new more minor change to the permissions (but still breaking). It removes the group-level access from the sensitive directories.

@zah zah merged commit 9c5cef3 into devel Nov 17, 2020
@zah zah deleted the perms branch November 17, 2020 21:28
@cheatfate
Copy link
Contributor

@zah couple of weeks already passed but there no new PR, so maybe i should open "security" issues because of that?

@zah
Copy link
Contributor

zah commented Nov 30, 2020

Yes, I think it's time that we fix this. Perhaps it can be addressed in the not yet merged passwordless keystores branch?

@cheatfate
Copy link
Contributor

@zah i have created new issue #2115

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants