Test failure: Test #3 in t1304-default-acl

Test failure: Test #3 in t1304-default-acl

[Ramkumar Ramachandra]

Hi,

The following test in t1304-default-acl.sh fails for me on the latest master:

test_expect_success SETFACL 'Objects creation does not break ACLs with
restrictive umask' '
	# SHA1 for empty blob
	check_perms_and_acl .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
'

It fails in the `grep -q "user:${LOGNAME}:rwx" actual` step, because
"actual" contains:

# file: .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
# owner: ramkum
# group: domain^users
user::r--
user:root:rwx   #effective:r--
user:kseygold:rwx       #effective:r--
group::---
mask::r--
other::---

I'm not sure who or what kseygold is.  I haven't dug any deeper.

Thanks.

Ram

Re: Test failure: Test #3 in t1304-default-acl

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> # file: .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
> # owner: ramkum
> # group: domain^users
> user::r--
> user:root:rwx   #effective:r--
> user:kseygold:rwx       #effective:r--
> group::---
> mask::r--
> other::---
>
> I'm not sure who or what kseygold is.

Do you have any user with this login (finger kseygold)? I suspect you
have two usernames with the same user ID.

Which filesystem are you using in this directory?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Test failure: Test #3 in t1304-default-acl

[Ramkumar Ramachandra]

Hi Matthieu,

Matthieu Moy wrote:
> Do you have any user with this login (finger kseygold)? I suspect you
> have two usernames with the same user ID.

Login: kseygold                         Name: Seybold
Directory: /home/likewise-open/ANT/kseygold     Shell: /bin/zsh
Office:  Kelly
Last login Tue Aug 28 12:16 (IST) on tty2
No mail.
No Plan.

> Which filesystem are you using in this directory?

/ is ext4.  What does that have to do with anything?

Ram

Re: Test failure: Test #3 in t1304-default-acl

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Hi Matthieu,
>
> Matthieu Moy wrote:
>> Do you have any user with this login (finger kseygold)? I suspect you
>> have two usernames with the same user ID.
>
> Login: kseygold                         Name: Seybold
> Directory: /home/likewise-open/ANT/kseygold     Shell: /bin/zsh
> Office:  Kelly
> Last login Tue Aug 28 12:16 (IST) on tty2
> No mail.
> No Plan.

Does this user have the same UID as your usual user
(id kseygold; id $LOGNAME)?

>> Which filesystem are you using in this directory?
>
> / is ext4.  What does that have to do with anything?

Last time we had a failure in this test, it was a filesystem bug ...

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Test failure: Test #3 in t1304-default-acl

[Ramkumar Ramachandra]

Hi again,

Matthieu Moy wrote:
> Does this user have the same UID as your usual user
> (id kseygold; id $LOGNAME)?

Yes.  What do you propose we do about the test?

Ram

Re: Test failure: Test #3 in t1304-default-acl

[Andreas Schwab]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Hi Matthieu,
>
> Matthieu Moy wrote:
>> Do you have any user with this login (finger kseygold)? I suspect you
>> have two usernames with the same user ID.
>
> Login: kseygold                         Name: Seybold

What about "id kseygold; id ramkum"?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Test failure: Test #3 in t1304-default-acl

[Ramkumar Ramachandra]

Hi Andreas,

Andreas Schwab wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Hi Matthieu,
>>
>> Matthieu Moy wrote:
>>> Do you have any user with this login (finger kseygold)? I suspect you
>>> have two usernames with the same user ID.
>>
>> Login: kseygold                         Name: Seybold
>
> What about "id kseygold; id ramkum"?

Apart from the UIDs matching, what do you find interesting about the output?

uid=1420023794(kseygold) gid=1419772417(domain^users)
groups=1419772417(domain^users),1419841836(sw-xchat-irc-client),1419932703(gref-sp-visitors),1419997311(fs-dus2-training-public),1420238821(sw-amazon-cloud-uploader),1419880095(dfs-pcsoft),1419980124(cs-psc-users),1419988839(scmdmauthorizedusers^(amzn-mdm)),1420131555(fs-lej1-oe-extern),1420053059(wireless-corporatewifi-allow),1419965136(sw-ms-ie7),1419812553(opr-pcsoft),1419806474(mac-caspershare-access),1419852490(dcolnl-accessrequestor),1419852491(dcolnl-visitorpre-registrationrequestor)
uid=1420023794(ramkum) gid=1419772417(domain^users)
groups=1419772417(domain^users),4(adm),20(dialout),24(cdrom),46(plugdev),116(lpadmin),118(admin),125(sambashare),1419841836(sw-xchat-irc-client),1419932703(gref-sp-visitors),1419997311(fs-dus2-training-public),1420238821(sw-amazon-cloud-uploader),1419992049(fhrix-employees),1419880095(dfs-pcsoft),1419988839(scmdmauthorizedusers^(amzn-mdm)),1420131555(fs-lej1-oe-extern),1420053059(wireless-corporatewifi-allow),1419812553(opr-pcsoft),1419806474(mac-caspershare-access),1419852490(dcolnl-accessrequestor),1419852491(dcolnl-visitorpre-registrationrequestor)

Ram

Re: Test failure: Test #3 in t1304-default-acl

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Hi again,
>
> Matthieu Moy wrote:
>> Does this user have the same UID as your usual user
>> (id kseygold; id $LOGNAME)?
>
> Yes.  What do you propose we do about the test?

On a GNU system, something like this should do the trick:

--- a/t/t1304-default-acl.sh
+++ b/t/t1304-default-acl.sh
@@ -31,9 +31,9 @@ fi
 
 check_perms_and_acl () {
        test -r "$1" &&
-       getfacl "$1" > actual &&
+       getfacl --numeric "$1" > actual &&
        grep -q "user:root:rwx" actual &&
-       grep -q "user:${LOGNAME}:rwx" actual &&
+       grep -q "user:$(id -u):rwx" actual &&
        egrep "mask::?r--" actual > /dev/null 2>&1 &&
        grep -q "group::---" actual || false
 }

but it seems FreeBSD's getfacl doesn't have --numeric
(http://www.unix.com/man-page/FreeBSD/1/getfacl/), so to be portable, we
need some more surgery, like this:

--- a/t/t1304-default-acl.sh
+++ b/t/t1304-default-acl.sh
@@ -33,7 +33,10 @@ check_perms_and_acl () {
        test -r "$1" &&
        getfacl "$1" > actual &&
        grep -q "user:root:rwx" actual &&
-       grep -q "user:${LOGNAME}:rwx" actual &&
+       grep "user:.*:rwx" actual | grep -v 'user:root:' | \
+           cut -d : -f 2 | xargs id -u > acl-uid &&
+       id -u > actual-uid &&
+       test_cmp acl-uid actual-uid &&
        egrep "mask::?r--" actual > /dev/null 2>&1 &&
        grep -q "group::---" actual || false
 }

Can you check that this second patch fixes your problem?

I'm a bit hesitant to submit it to git.git, as I find it a bit too
hacky. What do other people think?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Test failure: Test #3 in t1304-default-acl

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Hi again,
>>
>> Matthieu Moy wrote:
>>> Does this user have the same UID as your usual user
>>> (id kseygold; id $LOGNAME)?
>>
>> Yes.  What do you propose we do about the test?
>
> On a GNU system, something like this should do the trick:
> ...
> but it seems FreeBSD's getfacl doesn't have --numeric
> (http://www.unix.com/man-page/FreeBSD/1/getfacl/), so to be portable, we
> need some more surgery, like this:
>
> --- a/t/t1304-default-acl.sh
> +++ b/t/t1304-default-acl.sh
> @@ -33,7 +33,10 @@ check_perms_and_acl () {
>         test -r "$1" &&
>         getfacl "$1" > actual &&
>         grep -q "user:root:rwx" actual &&
> -       grep -q "user:${LOGNAME}:rwx" actual &&
> +       grep "user:.*:rwx" actual | grep -v 'user:root:' | \
> +           cut -d : -f 2 | xargs id -u > acl-uid &&
> +       id -u > actual-uid &&
> +       test_cmp acl-uid actual-uid &&
>         egrep "mask::?r--" actual > /dev/null 2>&1 &&
>         grep -q "group::---" actual || false
>  }
>
> Can you check that this second patch fixes your problem?
>
> I'm a bit hesitant to submit it to git.git, as I find it a bit too
> hacky. What do other people think?

I haven't been paying attention, but does that mean on that system,
a total stranger kseygold can write, modify, and remove whatever Ram
owns?  I am hoping that is not the case.

Re: Test failure: Test #3 in t1304-default-acl

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> I haven't been paying attention, but does that mean on that system,
> a total stranger kseygold can write, modify, and remove whatever Ram
> owns?  I am hoping that is not the case.

I can see two reasons for having the same UID for two login names:

1) the sysadmin really messed up, and as you say, a total stranger has
complete ownership of your files. Ramkumar, you should check that this
is not your case.

2) the sysadmin explicitely gave two login names to the same physical
person, as kinds of aliases for the same UID (e.g. the person got
married, changed her name and login, but expects ~oldlogin to continue
working). I'm not sure how common this is, and to which extend we want
to support this in our test scripts.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Test failure: Test #3 in t1304-default-acl

[Andreas Schwab]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Hi Andreas,
>
> Andreas Schwab wrote:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>
>>> Hi Matthieu,
>>>
>>> Matthieu Moy wrote:
>>>> Do you have any user with this login (finger kseygold)? I suspect you
>>>> have two usernames with the same user ID.
>>>
>>> Login: kseygold                         Name: Seybold
>>
>> What about "id kseygold; id ramkum"?
>
> Apart from the UIDs matching, what do you find interesting about the output?

That the UIDs are the same.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Test failure: Test #3 in t1304-default-acl

[Joachim Schmitz]

Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I haven't been paying attention, but does that mean on that system,
>> a total stranger kseygold can write, modify, and remove whatever Ram
>> owns?  I am hoping that is not the case.
>
> I can see two reasons for having the same UID for two login names:
>
> 1) the sysadmin really messed up, and as you say, a total stranger has
> complete ownership of your files. Ramkumar, you should check that this
> is not your case.
>
> 2) the sysadmin explicitely gave two login names to the same physical
> person, as kinds of aliases for the same UID (e.g. the person got
> married, changed her name and login, but expects ~oldlogin to continue
> working). I'm not sure how common this is, and to which extend we want
> to support this in our test scripts.

On HP NonStop it is very common to have a user (form: "GROUP.USER", case 
insensitiv) and one or more aliases to them (form: "user", case sensitiv) 
the latter are very commonly used in the POSIX part of HP NonStop (call 
OSS), the one git runs in, the other are more commonly used in the 
proprietary part of the OS (called Guardian), althoug this is not a strict 
requirement.
The only thing they share is the UID.

Bye, Jojo 

Re: Test failure: Test #3 in t1304-default-acl

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I haven't been paying attention, but does that mean on that system,
>> a total stranger kseygold can write, modify, and remove whatever Ram
>> owns?  I am hoping that is not the case.
>
> I can see two reasons for having the same UID for two login names:
>
> 1) the sysadmin really messed up, and as you say, a total stranger has
> complete ownership of your files. Ramkumar, you should check that this
> is not your case.
>
> 2) the sysadmin explicitely gave two login names to the same physical
> person, as kinds of aliases for the same UID (e.g. the person got
> married, changed her name and login, but expects ~oldlogin to continue
> working). I'm not sure how common this is, and to which extend we want
> to support this in our test scripts.

I've only been assuming (1), but (2) feels like a legitimate (if
confusing) way to configure your system.

It is a separate issue if it is worth bending backwards to support
it in the test, though.

Re: Test failure: Test #3 in t1304-default-acl

[Ramkumar Ramachandra]

Hi,

Matthieu Moy wrote:
> I can see two reasons for having the same UID for two login names:
>
> 1) the sysadmin really messed up, and as you say, a total stranger has
> complete ownership of your files. Ramkumar, you should check that this
> is not your case.

Looks like my sysadmin really screwed up :|

Ram

Re: Test failure: Test #3 in t1304-default-acl

[Ramkumar Ramachandra]

Hi Junio,

Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> I haven't been paying attention, but does that mean on that system,
>>> a total stranger kseygold can write, modify, and remove whatever Ram
>>> owns?  I am hoping that is not the case.
>>
>> I can see two reasons for having the same UID for two login names:
>>
>> 1) the sysadmin really messed up, and as you say, a total stranger has
>> complete ownership of your files. Ramkumar, you should check that this
>> is not your case.
>>
>> 2) the sysadmin explicitely gave two login names to the same physical
>> person, as kinds of aliases for the same UID (e.g. the person got
>> married, changed her name and login, but expects ~oldlogin to continue
>> working). I'm not sure how common this is, and to which extend we want
>> to support this in our test scripts.
>
> I've only been assuming (1), but (2) feels like a legitimate (if
> confusing) way to configure your system.
>
> It is a separate issue if it is worth bending backwards to support
> it in the test, though.

For what it's worth, `sudo` is "broken" on my system.

Ram

Re: Test failure: Test #3 in t1304-default-acl

[Joachim Schmitz]

Ramkumar Ramachandra wrote:
> Hi Junio,
>
> Junio C Hamano wrote:
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> I haven't been paying attention, but does that mean on that system,
>>>> a total stranger kseygold can write, modify, and remove whatever
>>>> Ram owns?  I am hoping that is not the case.
>>>
>>> I can see two reasons for having the same UID for two login names:
>>>
>>> 1) the sysadmin really messed up, and as you say, a total stranger
>>> has complete ownership of your files. Ramkumar, you should check
>>> that this is not your case.
>>>
>>> 2) the sysadmin explicitely gave two login names to the same
>>> physical person, as kinds of aliases for the same UID (e.g. the
>>> person got married, changed her name and login, but expects
>>> ~oldlogin to continue working). I'm not sure how common this is,
>>> and to which extend we want to support this in our test scripts.
>>
>> I've only been assuming (1), but (2) feels like a legitimate (if
>> confusing) way to configure your system.
>>
>> It is a separate issue if it is worth bending backwards to support
>> it in the test, though.
>
> For what it's worth, `sudo` is "broken" on my system.

sudo can't deal properly with multiple users sharing a UID, as it uses 
getpwuid(getuid()) in places.
On my system I've replaced that with getgwnam(getlogin()). which seems to 
work fine here.

Bye, Jojo 

Re: Test failure: Test #3 in t1304-default-acl

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Hi Junio,
>
> Junio C Hamano wrote:
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> I haven't been paying attention, but does that mean on that system,
>>>> a total stranger kseygold can write, modify, and remove whatever Ram
>>>> owns?  I am hoping that is not the case.
>>>
>>> I can see two reasons for having the same UID for two login names:
>>>
>>> 1) the sysadmin really messed up, and as you say, a total stranger has
>>> complete ownership of your files. Ramkumar, you should check that this
>>> is not your case.
>>>
>>> 2) the sysadmin explicitely gave two login names to the same physical
>>> person, as kinds of aliases for the same UID (e.g. the person got
>>> married, changed her name and login, but expects ~oldlogin to continue
>>> working). I'm not sure how common this is, and to which extend we want
>>> to support this in our test scripts.
>>
>> I've only been assuming (1), but (2) feels like a legitimate (if
>> confusing) way to configure your system.
>>
>> It is a separate issue if it is worth bending backwards to support
>> it in the test, though.
>
> For what it's worth, `sudo` is "broken" on my system.

Not very surprised ;-)