Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
brian m. carlson sand...@crustytoothpaste.net writes:
On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
}
}
This does not add extra cost in the normal case, and would fix this
particular issue for afp shares. So, I think that would fix the biggest
problem for afp-share users without disturbing others. It seems
reasonable to me to do that unconditionnally.
This can have security issues if you're trying to unlink a symlink, as
chmod will dereference the symlink but unlink will not. Giving the file
owner write permission may not be sufficient, as the user may be a
member of a group with write access to the repo. A malicious user who
also has access to the repo could force the current user to chmod an
arbitrary file such that it had looser permissions.
Ouch, indeed. I don't think that would be so problematic in practice (if
the attacker has access to the repo, it's easier to write arbitrary code
in hooks or config), but clearly we don't want to take the risk.
So, the right solution should be stg like Junio's
* in init-db.c, autoprobe by doing something like this:
create a test file with 0444 permission bits;
if (unlink(that test file)) {
chmod(that test file, 0644);
if (!unlink(that test file)) {
broken_unlink = 1;
git_config_set(core.brokenunlink, broken_unlink);
} else {
die(aaargh);
}
}
But when core.brokenunlink is set, just use 0666 instead of 0444 as
default mode for object files.
But right now, I'm not sure we're actually to work around an issue with
AFP shares or only one particular case of problematic configurtion for
one user.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
}
}
This does not add extra cost in the normal case, and would fix this
particular issue for afp shares. So, I think that would fix the biggest
problem for afp-share users without disturbing others. It seems
reasonable to me to do that unconditionnally.
This can have security issues if you're trying to unlink a symlink, as
chmod will dereference the symlink but unlink will not. Giving the file
owner write permission may not be sufficient, as the user may be a
member of a group with write access to the repo. A malicious user who
also has access to the repo could force the current user to chmod an
arbitrary file such that it had looser permissions.
I've seen a case where Perl's ExtUtils::MakeMaker chmoded
/etc/mime.types 0666 as a result of this.
I don't think there's a secure way to implement this unless you're on an
OS with lchmod or fchmodat that supports AT_SYMLINK_NOFOLLOW. Linux is
not one of those systems.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Torsten Bögershausen tbo...@web.de writes: On 17/02/15 17:58, Fairuzan Roslan wrote: $ rm -rf testdir rm: testdir/testfile: Operation not permitted rm: testdir: Directory not empty This works on my system (Mac OS 10.9 as server and client) Just to be sure: by work, you mean successfully removes the directory, right? The problem with Git failing is not because its inability to delete a directory but its inability to unlink and rename tmp_idx_XX and tmp_pack_XX because those files were set to 0444 by odb_mkstemp. Try google for “Git AFP” and you will see a lot people are facing with the same problem. Yes, (at least to my knowledge) you seem to be one of the first to report it here, thanks for that. And now I'm starting to wonder whether other people do have the same issue. Sure, googling Git AFP shows a lot of people having problems with Git and AFP, but are they really the same problem? I googled 'git afp unable to unlink', and all results except one point to this thread: https://www.google.com/search?q=git+afp+%22warning%3A+unable+to+unlink%22 The only one which doesn't actually does not mention afp. Fairuzan: are you sure you're not the only one having the issue? Can you give more info on your system (OS version client and server side, ...)? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: in compat/broken-unlink.c and something like this #ifdef BROKEN_UNLINK #define unlink(x) workaround_broken_unlink(x) #endif in git-compat-util.h instead? That means we have to know BROKEN_UNLINK at compile-time. I had never heard about AFP before this thread, but they seem mountable on Linux and Windows. I don't know whether these platforms will have the same issue, but I suspect they will (if the server rejects the unlink). So, if my suspicion is right, we'd have to activate it on any platform able to mount AFP, i.e. essentially everywhere. Sigh. That way, people on well behaving systems do not have to worry about clobbering errno and stuff, perhaps? With my solution, unlink() is always the last call in the function, so it should behave correctly right? Or did I miss anything? I am primarily worried about blindly attempting to run chmod() after seeing a failure from the first unlink() _without_ even making sure that the failure is caused by this silly bug in a single filesystem. If the first unlink() failed for some other reason, chmod() succeeded, and then the second unlink() failed for the same reason as the first failure (because the mode bits of the file being unlinked did not have anything to do with it), that would leave a file with wrong permission bits. And doing so when the user may know that there is no AFP involved in her set-up would be doubly wrong, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Junio C Hamano gits...@pobox.com writes: in compat/broken-unlink.c and something like this #ifdef BROKEN_UNLINK #define unlink(x) workaround_broken_unlink(x) #endif in git-compat-util.h instead? That means we have to know BROKEN_UNLINK at compile-time. I had never heard about AFP before this thread, but they seem mountable on Linux and Windows. I don't know whether these platforms will have the same issue, but I suspect they will (if the server rejects the unlink). So, if my suspicion is right, we'd have to activate it on any platform able to mount AFP, i.e. essentially everywhere. That way, people on well behaving systems do not have to worry about clobbering errno and stuff, perhaps? With my solution, unlink() is always the last call in the function, so it should behave correctly right? Or did I miss anything? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
in compat/broken-unlink.c and something like this
#ifdef BROKEN_UNLINK
#define unlink(x) workaround_broken_unlink(x)
#endif
in git-compat-util.h instead?
That means we have to know BROKEN_UNLINK at compile-time. I had never
heard about AFP before this thread, but they seem mountable on Linux and
Windows. I don't know whether these platforms will have the same issue,
but I suspect they will (if the server rejects the unlink).
So, if my suspicion is right, we'd have to activate it on any platform
able to mount AFP, i.e. essentially everywhere.
Sigh.
That is Sigh. It is unfortunate but you are correct..
Perhaps we would need to do something ugly like this:
* add core.brokenUnlink configuration (or whatever we end up
calling this filesystem trait) and add int broken_unlink in
environment.c (declare it in cache.h).
* in init-db.c, autoprobe by doing something like this:
create a test file with 0444 permission bits;
if (unlink(that test file)) {
chmod(that test file, 0644);
if (!unlink(that test file)) {
broken_unlink = 1;
git_config_set(core.brokenunlink, broken_unlink);
} else {
die(aaargh);
}
}
* Do your unlink_or_chmod() thing in wrapper.c, but perhaps call it
xunlink(), like this:
int xunlink(...) {
int ret = unlink(...);
if (broken_unlink ret) {
chmod(..., 0644);
ret = unlink(...);
}
return ret;
}
We probably need something similar for xrename()?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On Feb 18, 2015, at 10:05 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Fairuzan Roslan fairuzan.ros...@gmail.com writes: Client: OS X 10.9 - 10.10.2 git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1 Server : Linux 3.2.40 (Synology DSM 5.1) AFP : Netatalk afpd 3.1.1 Any chance you can test this with a Mac OS server? Perhaps because the server is not a Mac OS, it doesn't have the uchg flag, and maps it to the w bit in the POSIX permission system (this is pure speculation from me). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ I don’t have any Mac OS X server in my disposal at this moment but if you want to test out with netatalk AFPD I believe it’s available in debian ubuntu apt repo Regards, Fairuzan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Fairuzan Roslan fairuzan.ros...@gmail.com writes: Client: OS X 10.9 - 10.10.2 git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1 Server : Linux 3.2.40 (Synology DSM 5.1) AFP : Netatalk afpd 3.1.1 Any chance you can test this with a Mac OS server? Perhaps because the server is not a Mac OS, it doesn't have the uchg flag, and maps it to the w bit in the POSIX permission system (this is pure speculation from me). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On Feb 18, 2015, at 4:15 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: And now I'm starting to wonder whether other people do have the same issue. Sure, googling Git AFP shows a lot of people having problems with Git and AFP, but are they really the same problem? I googled 'git afp unable to unlink', and all results except one point to this thread: https://www.google.com/search?q=git+afp+%22warning%3A+unable+to+unlink%22 The only one which doesn't actually does not mention afp. Fairuzan: are you sure you're not the only one having the issue? Can you give more info on your system (OS version client and server side, …)? No I don’t think I’m the only one with the permission issue here but I’m sure many people prefer using smb over afp Client: OS X 10.9 - 10.10.2 git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1 Server : Linux 3.2.40 (Synology DSM 5.1) AFP : Netatalk afpd 3.1.1 From what I have tested whenever a file’s permission set to read-only on the AFP shares a user immutable flag were set as well hence why any action such as unlink or rename failed. $ ls -laO total 0 drwxr-xr-x 1 user staff - 264 Feb 18 21:31 . drwx-- 1 user staff - 264 Feb 18 21:31 .. -rw-r--r-- 1 user staff - 0 Feb 18 21:31 testfile $ chmod 0444 testfile; ls -laO total 0 drwxr-xr-x 1 user staff -264 Feb 18 21:31 . drwx-- 1 user staff -264 Feb 18 21:32 .. -r--r--r-- 1 user staff uchg 0 Feb 18 21:31 testfile I believe this to stop a read-only file to be modified by the user in Netatalk AFPD. $ chmod 0644 testfile; ls -laO total 0 drwxr-xr-x 1 user staff - 264 Feb 18 21:32 . drwx-- 1 user staff - 264 Feb 18 21:43 .. -rw-r--r-- 1 user staff - 0 Feb 18 21:31 testfile Changing the permission to read-write will remove the user immutable flag. Regards, Fairuzan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Matthieu Moy matthieu@grenoble-inp.fr writes:
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
}
}
I agree with the approach in principle, but I wonder if we want to
contaminate the generic codepath with unlink_or_chmod().
Don't we want to have this
#undef unlink
int workaround_broken_unlink(...) {
... the same ...
}
in compat/broken-unlink.c and something like this
#ifdef BROKEN_UNLINK
#define unlink(x) workaround_broken_unlink(x)
#endif
in git-compat-util.h instead? That way, people on well behaving
systems do not have to worry about clobbering errno and stuff,
perhaps?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On Feb 17, 2015, at 4:51 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects: 11830, done.
remote: Total 11830 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
Resolving deltas: 100% (6510/6510), done.
warning: unable to unlink
/Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation
not permitted
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
}
}
This does not add extra cost in the normal case, and would fix this
particular issue for afp shares. So, I think that would fix the biggest
problem for afp-share users without disturbing others. It seems
reasonable to me to do that unconditionnally.
$ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
What happens if you do rm -fr oh-my-zsh/.git/objects/pack/ (i.e.
remove the directory, not the files)?
If you can still remove the directory, then I'd say the solution above
could be sufficient: the user isn't supposed to interfer with the
content of .git/objects other than by using Git, and if he or she does,
then asking a chmod prior to an rm seems reasonable.
If you can't, then it's another problematic use-case (basically, you
can't just rm -fr a whole clone), and then it deserves at least an
opt-in configuration to get writable pack files.
(Unfortunately, I suspect we're in the later case)
If you insist on setting the tmp idx pack file permission to 0444 at
least give it a u+w permission whenever you try to unlink and rename
it so it won’t fail.
Yes. In case you hadn't guessed, this is precisely what I had in mind
when I asked Is it a problem when using Git [...] or when trying to
remove files outside Git?.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Yes. It’s a problem when using Git where it fails to unlink and rename the tmp
idx and pack files.
The reason I tries to rm -rf the tmp_idx_XX and tmp_pack_XX is to proof
a point why Git fails
Perhaps my explanation wasn’t clear enough. Maybe it’s hard for you to
understand without having to test it yourself on a AFP filesystem.
Let me explain why AFP filesystem is more strict and different from your
typical filesystem like ext4,hfs+,etc.
$ mkdir testdir; chmod 0755 testdir; touch testdir/testfile; chmod 0444
testdir/testfile; ls -la testdir
total 0
drwxr-xr-x 1 user staff 264 Feb 18 00:26 .
drwx-- 1 user staff 264 Feb 18 00:26 ..
-r--r--r-- 1 user staff0 Feb 18 00:26 testfile
$ rm -rf testdir
rm: testdir/testfile: Operation not permitted
rm: testdir: Directory not empty
$ chmod +w testdir/testfile; ls -la testdir
total 0
drwxr-xr-x 1 riaf staff 264 Feb 18 00:26 .
drwx-- 1 riaf staff 264 Feb 18 00:26 ..
-rw-r—r-- 1 riaf staff0 Feb 18 00:26 testfile
$ rm -rf testdir —— No error message
This show that you cannot delete a directory or a file without a write
permission in AFP filesystem.
The problem with Git failing is not because its inability to delete a directory
but its inability to unlink and rename tmp_idx_XX and tmp_pack_XX
because those files were set to 0444 by odb_mkstemp.
Try google for “Git AFP” and you will see a lot people are facing with the same
problem.
Regarding your suggestion, yes I think it would work but you have to take care
(chmod) every calls that rename or unlink or delete files with 0444 permission.
Regards,
Fairuzan
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On 17/02/15 17:58, Fairuzan Roslan wrote:
On Feb 17, 2015, at 4:51 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects: 11830, done.
remote: Total 11830 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
Resolving deltas: 100% (6510/6510), done.
warning: unable to unlink
/Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation
not permitted
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
}
}
This does not add extra cost in the normal case, and would fix this
particular issue for afp shares. So, I think that would fix the biggest
problem for afp-share users without disturbing others. It seems
reasonable to me to do that unconditionnally.
$ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
What happens if you do rm -fr oh-my-zsh/.git/objects/pack/ (i.e.
remove the directory, not the files)?
If you can still remove the directory, then I'd say the solution above
could be sufficient: the user isn't supposed to interfer with the
content of .git/objects other than by using Git, and if he or she does,
then asking a chmod prior to an rm seems reasonable.
If you can't, then it's another problematic use-case (basically, you
can't just rm -fr a whole clone), and then it deserves at least an
opt-in configuration to get writable pack files.
(Unfortunately, I suspect we're in the later case)
If you insist on setting the tmp idx pack file permission to 0444 at
least give it a u+w permission whenever you try to unlink and rename
it so it won’t fail.
Yes. In case you hadn't guessed, this is precisely what I had in mind
when I asked Is it a problem when using Git [...] or when trying to
remove files outside Git?.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Yes. It’s a problem when using Git where it fails to unlink and rename the
tmp idx and pack files.
The reason I tries to rm -rf the tmp_idx_XX and tmp_pack_XX is to
proof a point why Git fails
Perhaps my explanation wasn’t clear enough. Maybe it’s hard for you to
understand without having to test it yourself on a AFP filesystem.
Let me explain why AFP filesystem is more strict and different from your
typical filesystem like ext4,hfs+,etc.
$ mkdir testdir; chmod 0755 testdir; touch testdir/testfile; chmod 0444
testdir/testfile; ls -la testdir
total 0
drwxr-xr-x 1 user staff 264 Feb 18 00:26 .
drwx-- 1 user staff 264 Feb 18 00:26 ..
-r--r--r-- 1 user staff0 Feb 18 00:26 testfile
$ rm -rf testdir
rm: testdir/testfile: Operation not permitted
rm: testdir: Directory not empty
This works on my system (Mac OS 10.9 as server and client)
$ chmod +w testdir/testfile; ls -la testdir
total 0
drwxr-xr-x 1 riaf staff 264 Feb 18 00:26 .
drwx-- 1 riaf staff 264 Feb 18 00:26 ..
-rw-r—r-- 1 riaf staff0 Feb 18 00:26 testfile
$ rm -rf testdir —— No error message
This show that you cannot delete a directory or a file without a write
permission in AFP filesystem.
The problem with Git failing is not because its inability to delete a
directory but its inability to unlink and rename tmp_idx_XX and
tmp_pack_XX because those files were set to 0444 by odb_mkstemp.
Try google for “Git AFP” and you will see a lot people are facing with the
same problem.
Yes, (at least to my knowledge) you seem to be one of the first to report it
here, thanks for that.
Regarding your suggestion, yes I think it would work but you have to take
care (chmod) every calls that rename or unlink or delete files with 0444
permission.
Regards,
Fairuzan
The right solution is to make a wrapper function, and to re-define unlink()
and rename() with help
of the preprocessor.
git-compat-util.h has an example for fopen(), so that can be used for a patch.
And no, as I can not reproduce it here, I can only help with reviews or so.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects: 11830, done.
remote: Total 11830 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
Resolving deltas: 100% (6510/6510), done.
warning: unable to unlink
/Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not
permitted
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
}
}
This does not add extra cost in the normal case, and would fix this
particular issue for afp shares. So, I think that would fix the biggest
problem for afp-share users without disturbing others. It seems
reasonable to me to do that unconditionnally.
$ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
What happens if you do rm -fr oh-my-zsh/.git/objects/pack/ (i.e.
remove the directory, not the files)?
If you can still remove the directory, then I'd say the solution above
could be sufficient: the user isn't supposed to interfer with the
content of .git/objects other than by using Git, and if he or she does,
then asking a chmod prior to an rm seems reasonable.
If you can't, then it's another problematic use-case (basically, you
can't just rm -fr a whole clone), and then it deserves at least an
opt-in configuration to get writable pack files.
(Unfortunately, I suspect we're in the later case)
If you insist on setting the tmp idx pack file permission to 0444 at
least give it a u+w permission whenever you try to unlink and rename
it so it won’t fail.
Yes. In case you hadn't guessed, this is precisely what I had in mind
when I asked Is it a problem when using Git [...] or when trying to
remove files outside Git?.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
odb_mkstemp's 0444 permission broke write/delete access on AFP
Hi, Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares. In order to be able to write/unlink/delete/rename a file on AFP filesystem the owner of the file must have at least a u+w access to it. The issue was first introduced in https://github.com/git/git/blob/f80c7ae8fe9c0f3ce93c96a2dccaba34e456e33a/wrapper.c line 284. To fix these issues the permission need to be adjusted to “int mode = 0644;” in odb_mkstemp (environment.c) Please let me know if you need further detail. Regards, Fairuzan-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
I don’t see the issue for the owner of his/her own file to have write access. Setting tmp idx pack files to read-only even for the file owner is not a safety feature. The real issue here is that in AFP file system can’t even unlink or rename or delete the tmp idx and pack file with no write access after it done, while other file system like ext4,hfs+, etc can. You should at least give the user the option to set the permission in the config file and not hardcoded the permission in the binary. Regards, Fairuzan On Feb 17, 2015, at 2:23 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Fairuzan Roslan fairuzan.ros...@gmail.com writes: Hi, Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares. Is it a problem when using Git (like git gc failing to remove old packs), or when trying to remove files outside Git? The issue was first introduced in https://github.com/git/git/blob/f80c7ae8fe9c0f3ce93c96a2dccaba34e456e33a/wrapper.c line 284. I don't think so. The code before this commit did essentially a chmod 444 on the file, so object files were already read-only before. The pack files have been read-only since d83c9af5c6a437ddaa9dd27 (Junio, Apr 22 2007). To fix these issues the permission need to be adjusted to “int mode = 0644;” in odb_mkstemp (environment.c) The issue is that having object and pack files read-only on the filesystem is a safety feature to prevent accidental modifications (even though it's actually not that effective, since brute-force sed -i or perl -i still accept to modify read-only files). So, I'd be a bit reluctant to remove this safety feature for all users if it's only for the benefit of a minority of users. Not that I think the problem shouldn't be fixed, but I'd rather investigate alternate solutions before using this mode = 0644. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Matthieu Moy matthieu@grenoble-inp.fr writes: The issue is that having object and pack files read-only on the filesystem is a safety feature to prevent accidental modifications (even though it's actually not that effective, since brute-force sed -i or perl -i still accept to modify read-only files). I did not see it as a safety feature, and instead saw it as a reminder to me that I am not supposed to write into them when I check them with ls -l. So, I'd be a bit reluctant to remove this safety feature for all users if it's only for the benefit of a minority of users. Not that I think the problem shouldn't be fixed, but I'd rather investigate alternate solutions before using this mode = 0644. I fully agree with you that this should not be unconditional. However, I am not sure if there is an effective workaround to a filesystem that pays attention to the mode bits of the file when doing an operation on the directory the file is sitting within. It may be OK to introduce a new configuration variable, perhaps call it core.brokenFileSystemNeedsWritableFile or something, and probe and enable it inside init_db(). But I suspect that the single mode = 0444 under discussion may not cover all places we create files, as the assumption that the we get a sane semantics from the filesystem permeates throughout the code. What other glitches does AFP have? Does it share Windows' you cannot rename a file you have an open file descriptor on? Anything else? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On 16.02.15 20:06, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: The issue is that having object and pack files read-only on the filesystem is a safety feature to prevent accidental modifications (even though it's actually not that effective, since brute-force sed -i or perl -i still accept to modify read-only files). I did not see it as a safety feature, and instead saw it as a reminder to me that I am not supposed to write into them when I check them with ls -l. So, I'd be a bit reluctant to remove this safety feature for all users if it's only for the benefit of a minority of users. Not that I think the problem shouldn't be fixed, but I'd rather investigate alternate solutions before using this mode = 0644. I fully agree with you that this should not be unconditional. However, I am not sure if there is an effective workaround to a filesystem that pays attention to the mode bits of the file when doing an operation on the directory the file is sitting within. It may be OK to introduce a new configuration variable, perhaps call it core.brokenFileSystemNeedsWritableFile or something, and probe and enable it inside init_db(). But I suspect that the single mode = 0444 under discussion may not cover all places we create files, as the assumption that the we get a sane semantics from the filesystem permeates throughout the code. What other glitches does AFP have? Does it share Windows' you cannot rename a file you have an open file descriptor on? Anything else? May I ask which OS you have on the server side, and which on the client side? I'm aware that Mac OS speaks AFP, but even Linux can do and there is SW which enables AFP on a Windows machine (all this is server side). As a client we may have Mac OS, Linux (not sure if Windows can use APF) What do you use ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
[ Please, don't top post on this list ] Fairuzan Roslan fairuzan.ros...@gmail.com writes: I don’t see the issue for the owner of his/her own file to have write access. Object and pack files are not meant to be modified. Hence, they are read-only so that an (accidental) attempt to modify them fails. Setting tmp idx pack files to read-only even for the file owner is not a safety feature. Yes it is. If you do not think so, then please give some arguments. You should at least give the user the option to set the permission in the config file and not hardcoded the permission in the binary. This is the kind of thing I meant by investigate alternate solutions. I have no AFP share to test, so it would help if you answered the question I asked in my previous message: On Feb 17, 2015, at 2:23 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Fairuzan Roslan fairuzan.ros...@gmail.com writes: Hi, Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares. Is it a problem when using Git (like git gc failing to remove old packs), or when trying to remove files outside Git? (BTW, why did you try to write/rename pack files?) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
Fairuzan Roslan fairuzan.ros...@gmail.com writes: Hi, Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares. Is it a problem when using Git (like git gc failing to remove old packs), or when trying to remove files outside Git? The issue was first introduced in https://github.com/git/git/blob/f80c7ae8fe9c0f3ce93c96a2dccaba34e456e33a/wrapper.c line 284. I don't think so. The code before this commit did essentially a chmod 444 on the file, so object files were already read-only before. The pack files have been read-only since d83c9af5c6a437ddaa9dd27 (Junio, Apr 22 2007). To fix these issues the permission need to be adjusted to “int mode = 0644;” in odb_mkstemp (environment.c) The issue is that having object and pack files read-only on the filesystem is a safety feature to prevent accidental modifications (even though it's actually not that effective, since brute-force sed -i or perl -i still accept to modify read-only files). So, I'd be a bit reluctant to remove this safety feature for all users if it's only for the benefit of a minority of users. Not that I think the problem shouldn't be fixed, but I'd rather investigate alternate solutions before using this mode = 0644. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On 02/17/2015 04:22 AM, Fairuzan Roslan wrote: On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: [ Please, don't top post on this list ] Fairuzan Roslan fairuzan.ros...@gmail.com writes: I don’t see the issue for the owner of his/her own file to have write access. Object and pack files are not meant to be modified. Hence, they are read-only so that an (accidental) attempt to modify them fails. Setting tmp idx pack files to read-only even for the file owner is not a safety feature. Yes it is. If you do not think so, then please give some arguments. You should at least give the user the option to set the permission in the config file and not hardcoded the permission in the binary. This is the kind of thing I meant by investigate alternate solutions. I have no AFP share to test, so it would help if you answered the question I asked in my previous message: On Feb 17, 2015, at 2:23 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Fairuzan Roslan fairuzan.ros...@gmail.com writes: Hi, Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares. Is it a problem when using Git (like git gc failing to remove old packs), or when trying to remove files outside Git? (BTW, why did you try to write/rename pack files?) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ I think its easier if I just show you… OS : OS X 10.10.0 - 10.10.2 Client : git version 1.9.3 (Apple Git-50) and git version 2.2.1 AFP share : //user@hostname._afpovertcp._tcp.local/installer on /Volumes/installer (afpfs, nodev, nosuid, mounted by user) 1. git clone example $ git clone https://github.com/robbyrussell/oh-my-zsh.git Cloning into 'oh-my-zsh'... remote: Counting objects: 11830, done. remote: Total 11830 (delta 0), reused 0 (delta 0) Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done. Resolving deltas: 100% (6510/6510), done. warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted error: unable to write sha1 filename /Volumes/installer/oh-my-zsh/.git/objects/pack/pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.pack: Operation not permitted fatal: cannot store pack file fatal: index-pack failed $ ls -l oh-my-zsh/.git/objects/pack total 5008 -rw--- 1 user staff 32 Feb 17 09:59 pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.keep -r--r--r-- 1 user staff 332312 Feb 17 09:59 tmp_idx_oUN1sb -r--r--r-- 1 user staff 2223007 Feb 17 09:59 tmp_pack_zjPxuc $ rm -rf oh-my-zsh/.git/objects/pack/tmp_* rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted Detail Errors: 1. delete_ref_loose (refs.c) - unlink_or_msg (wrapper.c) - unable to unlink %s: %s 2. move_temp_to_file (sha1_file.c ) - “unable to write sha1 filename %s: %s” 2. git pull example Textual git:master $ git pull remote: Counting objects: 435, done. remote: Compressing objects: 100% (398/398), done. remote: Total 435 (delta 219), reused 18 (delta 12) Receiving objects: 100% (435/435), 1.22 MiB | 756.00 KiB/s, done. Resolving deltas: 100% (219/219), done. warning: unable to unlink .git/objects/pack/tmp_pack_vDaIZa: Operation not permitted error: unable to write sha1 filename .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack: Operation not permitted I'm somewhat unsure how this is connected to 0444 ? It seems as if you don't have write permissions for some reasons. (on the higher directory), what does ls -ld .git/objects/pack/ ls -ld .git/objects/ give ? can you run rm .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack on the command line ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: [ Please, don't top post on this list ] Fairuzan Roslan fairuzan.ros...@gmail.com writes: I don’t see the issue for the owner of his/her own file to have write access. Object and pack files are not meant to be modified. Hence, they are read-only so that an (accidental) attempt to modify them fails. Setting tmp idx pack files to read-only even for the file owner is not a safety feature. Yes it is. If you do not think so, then please give some arguments. You should at least give the user the option to set the permission in the config file and not hardcoded the permission in the binary. This is the kind of thing I meant by investigate alternate solutions. I have no AFP share to test, so it would help if you answered the question I asked in my previous message: On Feb 17, 2015, at 2:23 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Fairuzan Roslan fairuzan.ros...@gmail.com writes: Hi, Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares. Is it a problem when using Git (like git gc failing to remove old packs), or when trying to remove files outside Git? (BTW, why did you try to write/rename pack files?) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ I think its easier if I just show you… OS : OS X 10.10.0 - 10.10.2 Client : git version 1.9.3 (Apple Git-50) and git version 2.2.1 AFP share : //user@hostname._afpovertcp._tcp.local/installer on /Volumes/installer (afpfs, nodev, nosuid, mounted by user) 1. git clone example $ git clone https://github.com/robbyrussell/oh-my-zsh.git Cloning into 'oh-my-zsh'... remote: Counting objects: 11830, done. remote: Total 11830 (delta 0), reused 0 (delta 0) Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done. Resolving deltas: 100% (6510/6510), done. warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted error: unable to write sha1 filename /Volumes/installer/oh-my-zsh/.git/objects/pack/pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.pack: Operation not permitted fatal: cannot store pack file fatal: index-pack failed $ ls -l oh-my-zsh/.git/objects/pack total 5008 -rw--- 1 user staff 32 Feb 17 09:59 pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.keep -r--r--r-- 1 user staff 332312 Feb 17 09:59 tmp_idx_oUN1sb -r--r--r-- 1 user staff 2223007 Feb 17 09:59 tmp_pack_zjPxuc $ rm -rf oh-my-zsh/.git/objects/pack/tmp_* rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted Detail Errors: 1. delete_ref_loose (refs.c) - unlink_or_msg (wrapper.c) - unable to unlink %s: %s 2. move_temp_to_file (sha1_file.c ) - “unable to write sha1 filename %s: %s” 2. git pull example Textual git:master $ git pull remote: Counting objects: 435, done. remote: Compressing objects: 100% (398/398), done. remote: Total 435 (delta 219), reused 18 (delta 12) Receiving objects: 100% (435/435), 1.22 MiB | 756.00 KiB/s, done. Resolving deltas: 100% (219/219), done. warning: unable to unlink .git/objects/pack/tmp_pack_vDaIZa: Operation not permitted error: unable to write sha1 filename .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack: Operation not permitted fatal: cannot store pack file fatal: index-pack failed Textual git:master $ ls -l .git/objects/pack/tmp_* -r--r--r-- 1 user staff13252 Feb 17 10:51 .git/objects/pack/tmp_idx_uhnicb -r--r--r-- 1 user staff 1275487 Feb 17 10:51 .git/objects/pack/tmp_pack_vDaIZa = Same explanation as git clone example 3. git gc example Textual git:master $ git gc Counting objects: 49691, done. Delta compression using up to 4 threads. Compressing objects: 100% (11347/11347), done. fatal: unable to rename temporary pack file: Operation not permitted error: failed to run repack Textual git:master $ ls -l .git/objects/pack/tmp_* -r--r--r-- 1 user staff 1392420 Feb 17 10:58 .git/objects/pack/tmp_idx_77nr1b -r--r--r-- 1 user staff 96260304 Feb 17 10:58 .git/objects/pack/tmp_pack_RlAZc9 Detail Error: 1. finish_tmp_packfile (pack-write.c) - die_errno(“unable to rename temporary pack file”); If you insist on setting the tmp idx pack file permission to 0444 at least give it a u+w permission whenever you try to unlink and rename it so it won’t fail. Regards, Fairuzan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
On Feb 17, 2015, at 1:34 PM, Torsten Bögershausen tbo...@web.de wrote: On 02/17/2015 04:22 AM, Fairuzan Roslan wrote: On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: [ Please, don't top post on this list ] Fairuzan Roslan fairuzan.ros...@gmail.com writes: I don’t see the issue for the owner of his/her own file to have write access. Object and pack files are not meant to be modified. Hence, they are read-only so that an (accidental) attempt to modify them fails. Setting tmp idx pack files to read-only even for the file owner is not a safety feature. Yes it is. If you do not think so, then please give some arguments. You should at least give the user the option to set the permission in the config file and not hardcoded the permission in the binary. This is the kind of thing I meant by investigate alternate solutions. I have no AFP share to test, so it would help if you answered the question I asked in my previous message: On Feb 17, 2015, at 2:23 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Fairuzan Roslan fairuzan.ros...@gmail.com writes: Hi, Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares. Is it a problem when using Git (like git gc failing to remove old packs), or when trying to remove files outside Git? (BTW, why did you try to write/rename pack files?) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ I think its easier if I just show you… OS : OS X 10.10.0 - 10.10.2 Client : git version 1.9.3 (Apple Git-50) and git version 2.2.1 AFP share : //user@hostname._afpovertcp._tcp.local/installer on /Volumes/installer (afpfs, nodev, nosuid, mounted by user) 1. git clone example $ git clone https://github.com/robbyrussell/oh-my-zsh.git Cloning into 'oh-my-zsh'... remote: Counting objects: 11830, done. remote: Total 11830 (delta 0), reused 0 (delta 0) Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done. Resolving deltas: 100% (6510/6510), done. warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted error: unable to write sha1 filename /Volumes/installer/oh-my-zsh/.git/objects/pack/pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.pack: Operation not permitted fatal: cannot store pack file fatal: index-pack failed $ ls -l oh-my-zsh/.git/objects/pack total 5008 -rw--- 1 user staff 32 Feb 17 09:59 pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.keep -r--r--r-- 1 user staff 332312 Feb 17 09:59 tmp_idx_oUN1sb -r--r--r-- 1 user staff 2223007 Feb 17 09:59 tmp_pack_zjPxuc $ rm -rf oh-my-zsh/.git/objects/pack/tmp_* rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted Detail Errors: 1. delete_ref_loose (refs.c) - unlink_or_msg (wrapper.c) - unable to unlink %s: %s 2. move_temp_to_file (sha1_file.c ) - “unable to write sha1 filename %s: %s” 2. git pull example Textual git:master $ git pull remote: Counting objects: 435, done. remote: Compressing objects: 100% (398/398), done. remote: Total 435 (delta 219), reused 18 (delta 12) Receiving objects: 100% (435/435), 1.22 MiB | 756.00 KiB/s, done. Resolving deltas: 100% (219/219), done. warning: unable to unlink .git/objects/pack/tmp_pack_vDaIZa: Operation not permitted error: unable to write sha1 filename .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack: Operation not permitted I'm somewhat unsure how this is connected to 0444 ? It seems as if you don't have write permissions for some reasons. (on the higher directory), what does ls -ld .git/objects/pack/ ls -ld .git/objects/ give ? can you run rm .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack on the command line ? No. I have write permission on all of the folders. drwxr-xr-x 1 user staff 264 Feb 17 11:05 . drwxr-xr-x 1 user staff 264 Jan 30 12:52 .. It has nothing to do with my folder permissions. Like I said earlier this only happened to people who use AFP shares. When odb_mkstemp being called and sets the tmp idx pack files to 0444 and later functions like unlink_or_msg or finish_tmp_packfile tries to unlink or rename those files, it will fail It would be much faster and easier if you can try it on a AFP shares or I can talk you through it over irc @freenode #git (riaf^) Regards, Fairuzan signature.asc Description: Message signed with OpenPGP using GPGMail
