t4129 failure when sticky bit set

The new test (do not use core.sharedRepository for working tree files) in t4129-apply-sammode.sh does not account for sticky bits set:

  --- d_mode.expected     2020-12-30 11:56:11.869555700 +0000
  +++ d_mode.actual       2020-12-30 11:56:11.872889055 +0000
  @@ -1 +1 @@                                                
  -drwx------                                                
  +drwx--S---                                                

This sticky bit (g+s) is set on my home dir and thus inherrited.

The last test of t4129 creates a directory and expects its setgid bit (g+s) to be off. But this makes the test fail when the parent directory has the bit set, as setgid's state is inherited by newly created subdirectories. Make the test more robust by accepting the presence of the setgid bit on the created directory. We only allow 'S' (setgid on but no executable permission) and not 's' (setgid on with executable permission) because the previous 'umask 0077' shouldn't allow the second scenario to happen.

Note that only subdirectories inherit this bit, so we don't have to make the same change for the regular file that is also created by this test. But checking the permissions using grep instead of test_cmp makes the test a little simpler, so let's use it for the regular file as well.

Also note that the sticky bit (+t) and the setuid bit (u+s) are not inherited, so we don't have to worry about those.

Reported-by: Kevin Daudt <me@ikke.info>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
---
 t/t4129-apply-samemode.sh | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

On Wed, Dec 30, 2020 at 11:52:25AM -0300, Matheus Tavares wrote:

Tested-by: Kevin Daudt <me@ikke.info>

Matheus Tavares <matheus.bernardino@usp.br> writes:

It somehow feels to me that this approach would not scale well. Shouldn't this knowledge of inherited sticky gid bit hidden behind the test_modebits helper function?

Thanks.

The last test of t4129 creates a directory and expects its setgid bit (g+s) to be off. But this makes the test fail when the parent directory has the bit set, as setgid's state is inherited by newly created subdirectories.

One way to solve this problem is to allow the presence of this bit when comparing the return of `test_modebits` with the expected value. But then we may have the same problem in the future when other tests start using `test_modebits` on directories (currently t4129 is the only one) and forget about setgid. Instead, let's make the helper function more robust with respect to the state of the setgid bit in the test directory by removing this bit from the returning value. There should be no problem with existing callers as no one currently expects this bit to be on.

Note that the sticky bit (+t) and the setuid bit (u+s) are not inherited, so we don't have to worry about those.

Reported-by: Kevin Daudt <me@ikke.info>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
---
 t/test-lib-functions.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Matheus Tavares <matheus.bernardino@usp.br> writes:

We probably do not use "chmod g+s" manually on regular files, so I may be being overly "correct", but shouldn't these be done only for directories?

That is, 

			  -e 's|^\(d.....\)S|\1-|' -e 's|^\(d.....\)s|\1x|'

instead of applying the rule to any filetype.

Will queue as-is, as the distinction probably would not matter in practice.

Thanks.

On Wed, Jan 6, 2021 at 8:59 PM Junio C Hamano <gitster@pobox.com> wrote:

Yeah, you're right. I ended up applying the rule on regular files as well just for standardization. That is, if some day, for some reason, a test script decides to use "chmod g+s" on a regular file and a directory, test_modebits would treat them equally to avoid any confusion. But I guess it's very unlikely that we will ever need to set the setgid bit on a test, anyway...