public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@ir•bbn.com>
To: Jonathan Nieder <jrnieder@gmail•com>
Cc: Junio C Hamano <gitster@pobox•com>,
	git@vger•kernel.org, Alex Riesen <raa.lkml@gmail•com>,
	"Christopher M. Fuhrman" <cfuhrman@panix•com>,
	Stefan Sperling <stsp@stsp•name>
Subject: Re: [PATCH] Makefile: do not set setgid bit on directories on GNU/kFreeBSD
Date: Mon, 24 Oct 2011 19:07:52 -0400	[thread overview]
Message-ID: <rmibot6aszb.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <20111022111107.GA12130@elie.domain.sunraytvi.com> (Jonathan Nieder's message of "Sat, 22 Oct 2011 06:11:07 -0500")

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]


   * On some BSD systems, adding +s bit on directories is detrimental
     (it is not necessary on BSD to begin with). The installation
     procedure has been updated to take this into account.

I looked at the NetBSD 5 sources, and as expected files are created
(unconditionally) with the gid of the parent directory.

Setting the setgid flag is only allowed if the inode's gid is in the
process gid set.   This is really about files that might be executed,
but the check is independent of regular file/directory.

"git init --shared" creates a repository, mode 2775, and that normally
seems fine.  It seems good to have the sgid bit on, in case the
repository is transferred to another machine with different semantics,
and it's a clue to humans about the intended behavior, even if it's
non-optional on BSD.

I created a directory, mode 755, owned by me, and with group that I *do
not* belong to.  Then, "git init --shared" produced:

  fatal: Could not make /home/gdt/FOO/.git/refs writable by group

but really the issue was setting the sgid bit:

# all with git version 1.7.6.3
13 $ l -d .git/refs/
drwxr-xr-x  2 gdt  kmem  512 Oct 24 18:53 .git/refs/
14 $ chmod g+w .git/refs/
15 $ l -d .git/refs/
drwxrwxr-x  2 gdt  kmem  512 Oct 24 18:53 .git/refs/
16 $ chmod g+s .git/refs/
chmod: .git/refs/: Operation not permitted

However, this is a pathological situation, because I've created a shared
repository that I can write to because I own it, and group kmem people
can write to because they're in the group, but I couldn't write to other
group kmem resources.

Is this not-allowed-to-set-setgid issue the problem the patch is trying
to avoid?  Or something else?

I did run the regression tests at one point and don't remember this
failing.

So all in all I am agnostic as to whether DIR_HAS_BSD_GROUP_SEMANTICS
should be defined on NetBSD; personally I prefer to see the setgid
bits.


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

      reply	other threads:[~2011-10-24 23:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03  6:41 [PATCH] Makefile: do not set setgid bit on directories on GNU/kFreeBSD Jonathan Nieder
2011-10-03  7:19 ` Jonathan Nieder
2011-10-03 19:16   ` Junio C Hamano
2011-10-03 19:19     ` Sverre Rabbelier
2011-10-03 19:42       ` Jonathan Nieder
2011-10-22 11:11 ` Jonathan Nieder
2011-10-24 23:07   ` Greg Troxel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rmibot6aszb.fsf@fnord.ir.bbn.com \
    --to=gdt@ir$(echo .)bbn.com \
    --cc=cfuhrman@panix$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=jrnieder@gmail$(echo .)com \
    --cc=raa.lkml@gmail$(echo .)com \
    --cc=stsp@stsp$(echo .)name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox