threads / patch / 36584

patchconfig: preserve config file permissions on edits

Subject: [PATCH] config: preserve config file permissions on edits

## tl;dr

9 messages between May 5, 2014 and May 19, 2014. Diffs are folded; open one to read it.

replies: 8people: 6as markdown or json

Eric Wong· May 5, 2014, 21:58 UTC · lore

Users may already store sensitive data such as imap.pass in .git/config; making the file world-readable when "git config" is called to edit means their password would be compromised on a shared system.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 config.c               | 7 +++++++
 t/t1300-repo-config.sh | 6 ++++++
 2 files changed, 13 insertions(+)
Show changes to 2 files +13 −0

config.c, t/t1300-repo-config.sh

diff --git a/config.c b/config.c
index a30cb5c..a0b6756 100644
--- a/config.c
+++ b/config.c
@@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char *config_filename,
 			MAP_PRIVATE, in_fd, 0);
 		close(in_fd);
 
+		if (fchmod(fd, st.st_mode & 07777) < 0) {
+			error("fchmod on %s failed: %s",
+				lock->filename, strerror(errno));
+			ret = CONFIG_NO_WRITE;
+			goto out_free;
+		}
+
 		if (store.seen == 0)
 			store.seen = 1;
 
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 58cd543..d87693e 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1158,4 +1158,10 @@ test_expect_failure 'adding a key into an empty section reuses header' '
 	test_cmp expect .git/config
 '
 
+test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
+	chmod 0600 .git/config &&
+	git config imap.pass Hunter2 &&
+	perl -e "die q(badperm) if ((stat(q(.git/config)))[2] & 07777) != 0600"
+'
+
 test_done
-- 
Eric Wong
Eric Wong· May 6, 2014, 00:17 UTC · re: Eric Wong · lore

[PATCH v2] config: preserve config file permissions on edits

Users may already store sensitive data such as imap.pass in .git/config; making the file world-readable when "git config" is called to edit means their password would be compromised on a shared system.

[v2: updated for section renames, as noted by Junio]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 config.c               | 16 ++++++++++++++++
 t/t1300-repo-config.sh | 10 ++++++++++
 2 files changed, 26 insertions(+)
Show changes to 2 files +26 −0

config.c, t/t1300-repo-config.sh

diff --git a/config.c b/config.c
index a30cb5c..c227aa8 100644
--- a/config.c
+++ b/config.c
@@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char *config_filename,
 			MAP_PRIVATE, in_fd, 0);
 		close(in_fd);
 
+		if (fchmod(fd, st.st_mode & 07777) < 0) {
+			error("fchmod on %s failed: %s",
+				lock->filename, strerror(errno));
+			ret = CONFIG_NO_WRITE;
+			goto out_free;
+		}
+
 		if (store.seen == 0)
 			store.seen = 1;
 
@@ -1784,6 +1791,7 @@ int git_config_rename_section_in_file(const char *config_filename,
 	int out_fd;
 	char buf[1024];
 	FILE *config_file;
+	struct stat st;
 
 	if (new_name && !section_name_is_ok(new_name)) {
 		ret = error("invalid section name: %s", new_name);
@@ -1805,6 +1813,14 @@ int git_config_rename_section_in_file(const char *config_filename,
 		goto unlock_and_out;
 	}
 
+	fstat(fileno(config_file), &st);
+
+	if (fchmod(out_fd, st.st_mode & 07777) < 0) {
+		ret = error("fchmod on %s failed: %s",
+				lock->filename, strerror(errno));
+		goto out;
+	}
+
 	while (fgets(buf, sizeof(buf), config_file)) {
 		int i;
 		int length;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 58cd543..3f80ff0 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1158,4 +1158,14 @@ test_expect_failure 'adding a key into an empty section reuses header' '
 	test_cmp expect .git/config
 '
 
+test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
+	chmod 0600 .git/config &&
+	git config imap.pass Hunter2 &&
+	perl -e \
+	  "die q(badset) if ((stat(q(.git/config)))[2] & 07777) != 0600" &&
+	git config --rename-section imap pop &&
+	perl -e \
+	  "die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
+'
+
 test_done
-- 
Eric Wong
Jeff King· May 6, 2014, 22:02 UTC · re: Eric Wong · lore

Re: [PATCH v2] config: preserve config file permissions on edits

On Tue, May 06, 2014 at 12:17:14AM +0000, Eric Wong wrote:
> Users may already store sensitive data such as imap.pass in
> .git/config; making the file world-readable when "git config"
> is called to edit means their password would be compromised
> on a shared system.
Makes sense, and the patch looks good to me.
Show 5 quoted lines
> +test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
> +	chmod 0600 .git/config &&
> +	git config imap.pass Hunter2 &&
> +	perl -e \
> +	  "die q(badset) if ((stat(q(.git/config)))[2] & 07777) != 0600" &&

I don't think we usually bother with a PERL prereq for running one-liners like this from the test script, though I don't think it hurts anything to do so.

-Peff
Johannes Sixt· May 19, 2014, 07:13 UTC · re: Eric Wong · lore

Re: [PATCH v2] config: preserve config file permissions on edits

Am 5/6/2014 2:17, schrieb Eric Wong:
Show 27 quoted lines
> Users may already store sensitive data such as imap.pass in
> ..git/config; making the file world-readable when "git config"
> is called to edit means their password would be compromised
> on a shared system.
> 
> [v2: updated for section renames, as noted by Junio]
> 
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
>  config.c               | 16 ++++++++++++++++
>  t/t1300-repo-config.sh | 10 ++++++++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/config.c b/config.c
> index a30cb5c..c227aa8 100644
> --- a/config.c
> +++ b/config.c
> @@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char *config_filename,
>  			MAP_PRIVATE, in_fd, 0);
>  		close(in_fd);
>  
> +		if (fchmod(fd, st.st_mode & 07777) < 0) {
> +			error("fchmod on %s failed: %s",
> +				lock->filename, strerror(errno));
> +			ret = CONFIG_NO_WRITE;
> +			goto out_free;
> +		}

This introduces a severe failure in the Windows port because we do not implement fchmod. Existing fchmod invocations do not check the return value, and they are only interested in removing the write bits, and we generally don't care a lot if files remain writable.

I'm not proficient enough to add any ACL fiddling to fchmod that would be required by the above change, whose purpose is to be strict about permissions. Nor am I interested (who the heck is sharing a Windows box anyway? ;-)

Therefore, here's just a work-around patch to keep things going on Windows. Any opinions from the Windows corner?

--- >8 ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] mingw: turn the always-failing fchmod stub into always-succeeding

A recent change introduced new call sites of fchmod, but these new call sites check the return value. The test suite can't get past t0001 without a dozen or so failures.

Just fake that the call was successful even though it did nothing.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
 compat/mingw.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to compat/mingw.h +1 −1
diff --git a/compat/mingw.h b/compat/mingw.h
index c3859cc..7b2455c 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -89,7 +89,7 @@ static inline int readlink(const char *path, char *buf, size_t bufsiz)
 static inline int symlink(const char *oldpath, const char *newpath)
 { errno = ENOSYS; return -1; }
 static inline int fchmod(int fildes, mode_t mode)
-{ errno = ENOSYS; return -1; }
+{ /* do nothing */ return 0; }
 static inline pid_t fork(void)
 { errno = ENOSYS; return -1; }
 static inline unsigned int alarm(unsigned int seconds)
-- 
2.0.0.rc3.1741.g0520b9e

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Erik Faye-Lund· May 19, 2014, 07:44 UTC · re: Johannes Sixt · lore

Re: Re: [PATCH v2] config: preserve config file permissions on edits

On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 42 quoted lines
> Am 5/6/2014 2:17, schrieb Eric Wong:
>> Users may already store sensitive data such as imap.pass in
>> ..git/config; making the file world-readable when "git config"
>> is called to edit means their password would be compromised
>> on a shared system.
>>
>> [v2: updated for section renames, as noted by Junio]
>>
>> Signed-off-by: Eric Wong <normalperson@yhbt.net>
>> ---
>>  config.c               | 16 ++++++++++++++++
>>  t/t1300-repo-config.sh | 10 ++++++++++
>>  2 files changed, 26 insertions(+)
>>
>> diff --git a/config.c b/config.c
>> index a30cb5c..c227aa8 100644
>> --- a/config.c
>> +++ b/config.c
>> @@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char *config_filename,
>>                       MAP_PRIVATE, in_fd, 0);
>>               close(in_fd);
>>
>> +             if (fchmod(fd, st.st_mode & 07777) < 0) {
>> +                     error("fchmod on %s failed: %s",
>> +                             lock->filename, strerror(errno));
>> +                     ret = CONFIG_NO_WRITE;
>> +                     goto out_free;
>> +             }
>
> This introduces a severe failure in the Windows port because we do not
> implement fchmod. Existing fchmod invocations do not check the return
> value, and they are only interested in removing the write bits, and we
> generally don't care a lot if files remain writable.
>
> I'm not proficient enough to add any ACL fiddling to fchmod that would be
> required by the above change, whose purpose is to be strict about
> permissions. Nor am I interested (who the heck is sharing a Windows box
> anyway? ;-)
>
> Therefore, here's just a work-around patch to keep things going on
> Windows. Any opinions from the Windows corner?
>

Since we use MSVCRT's chmod implementation directly which only checks for S_IWRITE,and Get/SetFileAttributes to simply set or clear the FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same except using Get/SetFileInformationByHandle instead? That takes us in a better direction, IMO. Adding full ACL support seems like a bigger project.

If there's no objection, I'll sketch up a patch for that...
-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Erik Faye-Lund· May 19, 2014, 09:59 UTC · re: Erik Faye-Lund · lore

Re: Re: [PATCH v2] config: preserve config file permissions on edits

On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
Show 52 quoted lines
> On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Am 5/6/2014 2:17, schrieb Eric Wong:
>>> Users may already store sensitive data such as imap.pass in
>>> ..git/config; making the file world-readable when "git config"
>>> is called to edit means their password would be compromised
>>> on a shared system.
>>>
>>> [v2: updated for section renames, as noted by Junio]
>>>
>>> Signed-off-by: Eric Wong <normalperson@yhbt.net>
>>> ---
>>>  config.c               | 16 ++++++++++++++++
>>>  t/t1300-repo-config.sh | 10 ++++++++++
>>>  2 files changed, 26 insertions(+)
>>>
>>> diff --git a/config.c b/config.c
>>> index a30cb5c..c227aa8 100644
>>> --- a/config.c
>>> +++ b/config.c
>>> @@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char *config_filename,
>>>                       MAP_PRIVATE, in_fd, 0);
>>>               close(in_fd);
>>>
>>> +             if (fchmod(fd, st.st_mode & 07777) < 0) {
>>> +                     error("fchmod on %s failed: %s",
>>> +                             lock->filename, strerror(errno));
>>> +                     ret = CONFIG_NO_WRITE;
>>> +                     goto out_free;
>>> +             }
>>
>> This introduces a severe failure in the Windows port because we do not
>> implement fchmod. Existing fchmod invocations do not check the return
>> value, and they are only interested in removing the write bits, and we
>> generally don't care a lot if files remain writable.
>>
>> I'm not proficient enough to add any ACL fiddling to fchmod that would be
>> required by the above change, whose purpose is to be strict about
>> permissions. Nor am I interested (who the heck is sharing a Windows box
>> anyway? ;-)
>>
>> Therefore, here's just a work-around patch to keep things going on
>> Windows. Any opinions from the Windows corner?
>>
>
> Since we use MSVCRT's chmod implementation directly which only checks
> for S_IWRITE,and Get/SetFileAttributes to simply set or clear the
> FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same except
> using Get/SetFileInformationByHandle instead? That takes us in a
> better direction, IMO. Adding full ACL support seems like a bigger
> project.
>
> If there's no objection, I'll sketch up a patch for that...

OK, this turned out a bit more yucky than I assumed, because SetFileInformationByHandle is only available on Windows Vista and up. There's a static library (FileExtd.lib) that ships with MSVC that emulates it for legacy support, I guess I should have a look at what that does.

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thomas Braun· May 19, 2014, 19:17 UTC · re: Erik Faye-Lund · lore

Re: Re: [PATCH v2] config: preserve config file permissions on edits

Am Montag, den 19.05.2014, 11:59 +0200 schrieb Erik Faye-Lund:
Show 59 quoted lines
> On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> > On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >> Am 5/6/2014 2:17, schrieb Eric Wong:
> >>> Users may already store sensitive data such as imap.pass in
> >>> ..git/config; making the file world-readable when "git config"
> >>> is called to edit means their password would be compromised
> >>> on a shared system.
> >>>
> >>> [v2: updated for section renames, as noted by Junio]
> >>>
> >>> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> >>> ---
> >>>  config.c               | 16 ++++++++++++++++
> >>>  t/t1300-repo-config.sh | 10 ++++++++++
> >>>  2 files changed, 26 insertions(+)
> >>>
> >>> diff --git a/config.c b/config.c
> >>> index a30cb5c..c227aa8 100644
> >>> --- a/config.c
> >>> +++ b/config.c
> >>> @@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char *config_filename,
> >>>                       MAP_PRIVATE, in_fd, 0);
> >>>               close(in_fd);
> >>>
> >>> +             if (fchmod(fd, st.st_mode & 07777) < 0) {
> >>> +                     error("fchmod on %s failed: %s",
> >>> +                             lock->filename, strerror(errno));
> >>> +                     ret = CONFIG_NO_WRITE;
> >>> +                     goto out_free;
> >>> +             }
> >>
> >> This introduces a severe failure in the Windows port because we do not
> >> implement fchmod. Existing fchmod invocations do not check the return
> >> value, and they are only interested in removing the write bits, and we
> >> generally don't care a lot if files remain writable.
> >>
> >> I'm not proficient enough to add any ACL fiddling to fchmod that would be
> >> required by the above change, whose purpose is to be strict about
> >> permissions. Nor am I interested (who the heck is sharing a Windows box
> >> anyway? ;-)
> >>
> >> Therefore, here's just a work-around patch to keep things going on
> >> Windows. Any opinions from the Windows corner?
> >>
> >
> > Since we use MSVCRT's chmod implementation directly which only checks
> > for S_IWRITE,and Get/SetFileAttributes to simply set or clear the
> > FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same except
> > using Get/SetFileInformationByHandle instead? That takes us in a
> > better direction, IMO. Adding full ACL support seems like a bigger
> > project.
> >
> > If there's no objection, I'll sketch up a patch for that...
> 
> OK, this turned out a bit more yucky than I assumed, because
> SetFileInformationByHandle is only available on Windows Vista and up.
> There's a static library (FileExtd.lib) that ships with MSVC that
> emulates it for legacy support, I guess I should have a look at what
> that does.

Do we still want to fully support Windows XP? Adding a work around here for a EOL operating system sounds like a lot of effort.

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Erik Faye-Lund· May 19, 2014, 19:21 UTC · re: Thomas Braun · lore

Re: Re: [PATCH v2] config: preserve config file permissions on edits

On Mon, May 19, 2014 at 9:17 PM, Thomas Braun <thomas.braun@virtuell-zuhause.de> wrote:

Show 64 quoted lines
> Am Montag, den 19.05.2014, 11:59 +0200 schrieb Erik Faye-Lund:
>> On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> > On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> >> Am 5/6/2014 2:17, schrieb Eric Wong:
>> >>> Users may already store sensitive data such as imap.pass in
>> >>> ..git/config; making the file world-readable when "git config"
>> >>> is called to edit means their password would be compromised
>> >>> on a shared system.
>> >>>
>> >>> [v2: updated for section renames, as noted by Junio]
>> >>>
>> >>> Signed-off-by: Eric Wong <normalperson@yhbt.net>
>> >>> ---
>> >>>  config.c               | 16 ++++++++++++++++
>> >>>  t/t1300-repo-config.sh | 10 ++++++++++
>> >>>  2 files changed, 26 insertions(+)
>> >>>
>> >>> diff --git a/config.c b/config.c
>> >>> index a30cb5c..c227aa8 100644
>> >>> --- a/config.c
>> >>> +++ b/config.c
>> >>> @@ -1636,6 +1636,13 @@ int git_config_set_multivar_in_file(const char *config_filename,
>> >>>                       MAP_PRIVATE, in_fd, 0);
>> >>>               close(in_fd);
>> >>>
>> >>> +             if (fchmod(fd, st.st_mode & 07777) < 0) {
>> >>> +                     error("fchmod on %s failed: %s",
>> >>> +                             lock->filename, strerror(errno));
>> >>> +                     ret = CONFIG_NO_WRITE;
>> >>> +                     goto out_free;
>> >>> +             }
>> >>
>> >> This introduces a severe failure in the Windows port because we do not
>> >> implement fchmod. Existing fchmod invocations do not check the return
>> >> value, and they are only interested in removing the write bits, and we
>> >> generally don't care a lot if files remain writable.
>> >>
>> >> I'm not proficient enough to add any ACL fiddling to fchmod that would be
>> >> required by the above change, whose purpose is to be strict about
>> >> permissions. Nor am I interested (who the heck is sharing a Windows box
>> >> anyway? ;-)
>> >>
>> >> Therefore, here's just a work-around patch to keep things going on
>> >> Windows. Any opinions from the Windows corner?
>> >>
>> >
>> > Since we use MSVCRT's chmod implementation directly which only checks
>> > for S_IWRITE,and Get/SetFileAttributes to simply set or clear the
>> > FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same except
>> > using Get/SetFileInformationByHandle instead? That takes us in a
>> > better direction, IMO. Adding full ACL support seems like a bigger
>> > project.
>> >
>> > If there's no objection, I'll sketch up a patch for that...
>>
>> OK, this turned out a bit more yucky than I assumed, because
>> SetFileInformationByHandle is only available on Windows Vista and up.
>> There's a static library (FileExtd.lib) that ships with MSVC that
>> emulates it for legacy support, I guess I should have a look at what
>> that does.
>
> Do we still want to fully support Windows XP?
> Adding a work around here for a EOL operating system sounds like a lot
> of effort.

I personally don't care about Windows XP, but some other influential people (J6T IIRC) disagreed the last time this was discussed. I don't want to step on anyone's toes.

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marius Storm-Olsen· May 19, 2014, 15:59 UTC · re: Erik Faye-Lund · lore

Re: Re: [PATCH v2] config: preserve config file permissions on edits

On 5/19/2014 2:44 AM, Erik Faye-Lund wrote:
Show 15 quoted lines
> On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt <j.sixt@viscovery.net>
> wrote:
>> I'm not proficient enough to add any ACL fiddling to fchmod that
>> would be required by the above change, whose purpose is to be
>> strict about permissions. Nor am I interested (who the heck is
>> sharing a Windows box anyway? ;-)
>
> Since we use MSVCRT's chmod implementation directly which only
> checks for S_IWRITE,and Get/SetFileAttributes to simply set or clear
> the FILE_ATTRIBUTE_READONLY-flag, perhaps we could do the same
> except using Get/SetFileInformationByHandle instead? That takes us in
> a better direction, IMO. Adding full ACL support seems like a bigger
> project.
>
> If there's no objection, I'll sketch up a patch for that...

IMO, try to stay away from full ACL support, as ACL is slow as hell. If it's only triggered in edge cases, that's fine, but be sure not to add any ACL in the main call-paths as it will surely kill performance.

The major speedup which was done by circumventing MSYS/Cygwin standard posix implementations was bypassing much of the ACL slowness.

-- 
.marius

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

← back to recent threads