Re: [PATCH] commit: ensure correct permissions of the commit message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Dec 20, 2015 at 05:31:48PM -0800, Junio C Hamano wrote:

> Actually, we do not even _need_ a sharedness for this ephemeral
> file.  The additional "adjust-shared-perm" is merely a workaround
> for the fact the next person cannot write into it when it is left
> behind, and because we do not want to remove it when we are done.
> 
> That does not measn that the next person cannot remove it when she
> finds there is a file there left behind.  So alternatively, we could
> do something like this, perhaps?
> 
>         FILE *fopen_forcibly(const char *path, const char *mode)
>         {
>                 FILE *ret = fopen(path, mode);
> 
>                 if (!ret && errno == EPERM) {
>                         if (!unlink(path))
>                                 ret = fopen(path, mode);
>                         else
>                                 errno = EPERM;
>                 }
>                 return ret;
>         }

Yeah, I think that is a much nicer solution for this case. It should
work even in a shared repo, since we set the permissions for the
surrounding $GIT_DIR appropriately[1].

I guess it would not apply to any files that do not want to truncate the
existing contents. Probably it should drop the "mode" parameter at all,
since anything but "w" would be crazy?

-Peff

[1] Assuming you use something like "git init --shared=true". I would
    not be surprised if there are many repos where somebody just set
    "core.sharedrepository" after the fact, but there is not much we can
    do. They _have_ to fix up the permissions in that case.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]