Re: odb_mkstemp's 0444 permission broke write/delete access on AFP
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Feb 19, 2015, 20:08 UTC
- Message-ID
- <20150219200833.GB5021@vauxhall.crustytoothpaste.net>
- In-Reply-To
- <vpqr3tozzs5.fsf@anie.imag.fr>
On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
Show 14 quoted lines
> 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