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

Restore original files permissions #922

Merged
merged 1 commit into from
Jul 20, 2016
Merged

Restore original files permissions #922

merged 1 commit into from
Jul 20, 2016

Conversation

joegrasse
Copy link
Contributor

This fixes #921.

@@ -41,7 +41,11 @@ function! go#asmfmt#Format()

" Replace the current file with the temp file; then reload the buffer.
let old_fileformat = &fileformat
" save old file permissions
let original_fperm = getfperm(expand('%'))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the doc this also returns - if the user does not have the given permission. We should test if the variable is - below before we set it to prevent unwanted errors.

@fatih
Copy link
Owner

fatih commented Jun 30, 2016

Thanks @joegrasse. If you add the check in setfperm() before overriding the permission we're good to go.

@joegrasse
Copy link
Contributor Author

Actually I believe we don't want the check for -. In my scenario in #921, the original file would have returned -rw-rw-rw-. After editing the file, with my umask set to 0022, it would become -rw-r--r--. With my change above it stays -rw-rw-rw- after editing. So a - is actually a valid scenario.

@fatih
Copy link
Owner

fatih commented Jun 30, 2016

The problem is that it should not set the permissions when getfperm returns a -. It's an edge case we don't want. So you should add an if clause just before setfperm to avoid this.

@joegrasse
Copy link
Contributor Author

I sorry, I guess I am not following you. Are you thinking there is the case where it would return only -? Even if the file is chmoded as 000, it would still return ---------. What the doc is saying is, if the file doesn't has a specific permission it returns -. So if the file doesn't have the group writable permission it would give a - in that permission slot instead of w.

@gabrielsjoberg
Copy link

Passing "-" back into setfperm() turns the relevant permission off, which is the expected behavior if the original file also did not have that permission. Calling something like the following would essentially be a NOOP:

setfperm(file, getfperm(file))

However, in the reported bug, there are two separate files: the original one with the intended permissions and a temp file that has different (wrong) permissions due to the user's umask. When the temp file is moved over the original file, the temp file's permissions overwrite the original, intended permissions. This could lead to problems such as a world-writable file suddenly becoming read-only to everyone but the current user (or worse, it could happen the other way around).

This PR reapplies the permissions from the original file to the temp file exactly as they were. When the temp file is moved into place, it will have the same permissions as it did before calling fmt(), with no new permissions added and no previous permissions lost. Other than verifying that getfperm() does not return an empty string, no further checks or modifications of the perm string are necessary.

@joegrasse
Copy link
Contributor Author

Do the last couple of comments clear your questions up for you, or do you still have concerns?

@fatih fatih merged commit 902f626 into fatih:master Jul 20, 2016
@fatih
Copy link
Owner

fatih commented Jul 20, 2016

Thanks @joegrasse

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.

Original file permissions are lost on gofmt
3 participants