Git config command ignores explicitly set file permissions

Git config command ignores explicitly set file permissions

[Riddell, Matthew A]

Hello,

I noticed while working with Git that the file permissions on the gitconfig file is ignored and the parent folder permissions are used instead to update the file. 
An example is as follows:

Before running git config ensure the user running the command is not able to edit the file but has read access to the file. Ensure the User has full access to the parent folder. 
After running any git config command the user previously without edit permissions on a file can now edit the config file.

I documented the issue in more details in this ticket https://github.com/git-for-windows/git/issues/2686

I originally found the issue  while working in the windows version of git but @dscho noted that it is also an issue in the WSL version of git and believes it is caused by creating the .lock file which replaces the original file.
@dscho also suggested I send out an email to this mailing list.

Let me know if I can provide any more information

Thanks,

Matthew Riddell

----------------------------------------------------------------------
The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.

Re: Git config command ignores explicitly set file permissions

[Junio C Hamano]

"Riddell, Matthew A" <mriddell@paychex.com> writes:

> I noticed while working with Git that the file permissions on the
> gitconfig file is ignored and the parent folder permissions are
> used instead to update the file.  An example is as follows:
>
> Before running git config ensure the user running the command is
> not able to edit the file but has read access to the file. Ensure
> the User has full access to the parent folder.  After running any
> git config command the user previously without edit permissions on
> a file can now edit the config file.

That is pretty much how things are intended to work on a filesystem
and is not limited to Git.  Your arrangement, contrary to what you
said, does not "ensure the user running the command is not able to
edit but has read access".

    mkdir newdir
    chmod +rwx newdir
    >newdir/file
    chmod a-w newdir/file

would not forbid you from doing

    rm -f newdir/file
    ehco new >newdir/file

In other words, if you allow your user to write to a directory, you
cannot forbid the user from creating and removing files in it.

RE: Git config command ignores explicitly set file permissions

[Randall S. Becker]

On June 18, 2020 2:32 PM, Junio C Hamano wrote:
> "Riddell, Matthew A" <mriddell@paychex.com> writes:
> > I noticed while working with Git that the file permissions on the
> > gitconfig file is ignored and the parent folder permissions are used
> > instead to update the file.  An example is as follows:
> >
> > Before running git config ensure the user running the command is not
> > able to edit the file but has read access to the file. Ensure the User
> > has full access to the parent folder.  After running any git config
> > command the user previously without edit permissions on a file can now
> > edit the config file.

Forgive me to asking, but is this an attempt at replicating what other VCS
systems do? ClearCase is an example where files are forced to read-only and
if the user wants to modify it, then they have to ask nicely for a lock on
the file. The use of "read only" is a semi-guarantee that a user will not
modify code and interfere with other users. In git, the rules are quite
different, where modification resolution occurs later in the process.

> That is pretty much how things are intended to work on a filesystem and is
> not limited to Git.  Your arrangement, contrary to what you said, does not
> "ensure the user running the command is not able to edit but has read
> access".
> 
>     mkdir newdir
>     chmod +rwx newdir
>     >newdir/file
>     chmod a-w newdir/file
> 
> would not forbid you from doing
> 
>     rm -f newdir/file
>     ehco new >newdir/file
> 
> In other words, if you allow your user to write to a directory, you cannot
> forbid the user from creating and removing files in it.

Just inquiring about this, as git operational decisions are fundamentally
different from older systems.

Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Git config command ignores explicitly set file permissions

[Riddell, Matthew A]

> "Riddell, Matthew A" <mriddell@paychex.com> writes:
> > I noticed while working with Git that the file permissions on the 
> > gitconfig file is ignored and the parent folder permissions are used 
> > instead to update the file.  An example is as follows:
> >
> > Before running git config ensure the user running the command is not 
> > able to edit the file but has read access to the file. Ensure the 
> > User has full access to the parent folder.  After running any git 
> > config command the user previously without edit permissions on a 
> > file can now edit the config file.

>>Forgive me to asking, but is this an attempt at replicating what other VCS systems do? ClearCase is an example where files are forced to read-only and if the user wants to modify it, then they have to ask nicely for a >>lock on the file. The use of "read only" is a semi-guarantee that a user will not modify code and interfere with other users. In git, the rules are quite different, where modification resolution occurs later in the process.

We have had problems in our continuous integration environment with builds modifying the global configuration of tools. I came across this issue trying to lock down our git global configuration for the local user running our builds. The workaround I found is creating a symlink from the user home directory to another folder (which has read only permissions) which contains the actual gitconfig file.

-----Original Message-----
From: Randall S. Becker <rsbecker@nexbridge.com> 
Sent: Thursday, June 18, 2020 4:30 PM
To: 'Junio C Hamano' <gitster@pobox.com>; Riddell, Matthew A <mriddell@paychex.com>
Cc: git@vger.kernel.org
Subject: RE: Git config command ignores explicitly set file permissions


Warning: This email is from outside the company. Be careful clicking links or attachments.

On June 18, 2020 2:32 PM, Junio C Hamano wrote:
> "Riddell, Matthew A" <mriddell@paychex.com> writes:
> > I noticed while working with Git that the file permissions on the 
> > gitconfig file is ignored and the parent folder permissions are used 
> > instead to update the file.  An example is as follows:
> >
> > Before running git config ensure the user running the command is not 
> > able to edit the file but has read access to the file. Ensure the 
> > User has full access to the parent folder.  After running any git 
> > config command the user previously without edit permissions on a 
> > file can now edit the config file.

Forgive me to asking, but is this an attempt at replicating what other VCS systems do? ClearCase is an example where files are forced to read-only and if the user wants to modify it, then they have to ask nicely for a lock on the file. The use of "read only" is a semi-guarantee that a user will not modify code and interfere with other users. In git, the rules are quite different, where modification resolution occurs later in the process.

> That is pretty much how things are intended to work on a filesystem 
> and is not limited to Git.  Your arrangement, contrary to what you 
> said, does not "ensure the user running the command is not able to 
> edit but has read access".
> 
>     mkdir newdir
>     chmod +rwx newdir
>     >newdir/file
>     chmod a-w newdir/file
> 
> would not forbid you from doing
> 
>     rm -f newdir/file
>     ehco new >newdir/file
> 
> In other words, if you allow your user to write to a directory, you 
> cannot forbid the user from creating and removing files in it.

Just inquiring about this, as git operational decisions are fundamentally different from older systems.

Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000  UNIX developer since approximately 421664400
-- In my real life, I talk too much.



----------------------------------------------------------------------
The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.

RE: Git config command ignores explicitly set file permissions

[Randall S. Becker]

On June 18, 2020 4:57 PM, Matthew wrote:
> > "Riddell, Matthew A" <mriddell@paychex.com> writes:
> > > I noticed while working with Git that the file permissions on the
> > > gitconfig file is ignored and the parent folder permissions are used
> > > instead to update the file.  An example is as follows:
> > >
> > > Before running git config ensure the user running the command is not
> > > able to edit the file but has read access to the file. Ensure the
> > > User has full access to the parent folder.  After running any git
> > > config command the user previously without edit permissions on a
> > > file can now edit the config file.
> 
> >>Forgive me to asking, but is this an attempt at replicating what other
VCS
> systems do? ClearCase is an example where files are forced to read-only
and
> if the user wants to modify it, then they have to ask nicely for a >>lock
on the
> file. The use of "read only" is a semi-guarantee that a user will not
modify
> code and interfere with other users. In git, the rules are quite
different,
> where modification resolution occurs later in the process.
> 
> We have had problems in our continuous integration environment with builds
> modifying the global configuration of tools. I came across this issue
trying to
> lock down our git global configuration for the local user running our
builds.
> The workaround I found is creating a symlink from the user home directory
> to another folder (which has read only permissions) which contains the
> actual gitconfig file.

As a suggestion, you might want to add a git status -uno --porcelain to key
parts of your scripts to find the conditions where that is occurring and
fail the job if the output is not empty. CI tools and applications should
not change configurations unexpectedly and that would be a pipeline stage
failure - in my books anyway.