Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Take umask into account in filebuf_commit #1940

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

Merged
merged 2 commits into from
Nov 5, 2013

Conversation

ethomson
Copy link
Member

@ethomson ethomson commented Nov 4, 2013

Our usage of git_filebuf_commit indicates that it would take umask into account, but it does not. (See, for instance, config_file.c.

@carlosmn
Copy link
Member

carlosmn commented Nov 4, 2013

The OS is the one that's meant to take the umask into account. When you write out a file and ask for 0777, the OS will apply the umask and leave that in e.g. 0755. It seems really strange that we would have to do it ourselves.

@ethomson
Copy link
Member Author

ethomson commented Nov 4, 2013

No, we explicitly call chmod.

@arrbee
Copy link
Member

arrbee commented Nov 4, 2013

I think @carlosmn is correct and we should probably just not call chmod in this case. I'm not quite sure what the implications of that are without doing a more thorough audit of the places that use this code, though...

@ethomson
Copy link
Member Author

ethomson commented Nov 4, 2013

So you want to move the mode to open? Does win32 preserve mode across
renames?

On Mon, Nov 4, 2013 at 5:08 PM, Russell Belfer [email protected]:

I think @carlosmn https://github.com/carlosmn is correct and we should
probably just not call chmod in this case. I'm not quite sure what the
implications of that are without doing a more thorough audit of the places
that use this code, though...


Reply to this email directly or view it on GitHubhttps://github.com//pull/1940#issuecomment-27727651
.

@carlosmn
Copy link
Member

carlosmn commented Nov 4, 2013

Ah, you're right.When calling chmod do we have to it ourselves, but we probably shouldn't be doing that at all, as git_futils_creat_locked already opens with the specified mode. The chmod call overwrites the OS' hard work.

If Win32 doesn't preserve the mode across renames, then we're still buggy (and have been for a while), as the rename call happens after the chmod of the locked file.

@carlosmn
Copy link
Member

carlosmn commented Nov 4, 2013

Ok, so it's a pretty large change to refactor this now to fix the issue. We should do this in the future, as the call to chmod is silly when we always know beforehand what mode we want to write with and should just do the sensible thing and tell open; but we missed that when reviewing the incoming changes.

So let's go with this and we can do the refactor later on, as it's purely an internal API.

@ethomson
Copy link
Member Author

ethomson commented Nov 4, 2013

Well, we also call mkstemp, so we'd need to call chmod either way in
that case.

I think that the only advantage to doing it in git_filebuf_open is that
it is reminiscent of open(2). Which would be very nice indeed, but yes,
getting this fixed would be very nice and fixing the API would be nice to
have.

On Mon, Nov 4, 2013 at 5:36 PM, Carlos Martín Nieto <
[email protected]> wrote:

Ok, so it's a pretty large change to refactor this now to fix the issue.
We should do this in the future, as the call to chmod is silly when we
always know beforehand what mode we want to write with and should just do
the sensible thing and tell open; but we missed that when reviewing the
incoming changes.

So let's go with this and we can do the refactor later on, as it's purely
an internal API.


Reply to this email directly or view it on GitHubhttps://github.com//pull/1940#issuecomment-27729890
.

@ethomson
Copy link
Member Author

ethomson commented Nov 4, 2013

Okay, let's move that then so that we can get this merged. World writable files in the git repo are for real bad.

@ethomson ethomson mentioned this pull request Nov 5, 2013
@ethomson
Copy link
Member Author

ethomson commented Nov 5, 2013

Yo lets merge this so the build turns green and we stop writing world writable files. @cmn are you happy with the API change?

@carlosmn
Copy link
Member

carlosmn commented Nov 5, 2013

👍 ❤️

ethomson added a commit that referenced this pull request Nov 5, 2013
Take umask into account in filebuf_commit
@ethomson ethomson merged commit 3ae66ef into libgit2:development Nov 5, 2013
phatblat pushed a commit to phatblat/libgit2 that referenced this pull request Sep 13, 2014
Take umask into account in filebuf_commit
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.

3 participants