RE: Git config command ignores explicitly set file permissions

From: Randall S. Becker <rsbecker@nexbridge.com>
Date: Jun 18, 2020, 20:30 UTC
Message-ID: <022601d645af$45d0e640$d172b2c0$@nexbridge.com>
In-Reply-To: <xmqqsgesns22.fsf@gitster.c.googlers.com>

On June 18, 2020 2:32 PM, Junio C Hamano wrote:

Show 10 quoted lines

> "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.

Show 17 quoted lines

> 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.