fsgqa group membership?

fsgqa group membership?

[Richard Weinberger]

Hi!

After migrating to a new test environment, I observed that generic/193 failed.
Initially, I assumed it was a UBIFS regression, but it appears that all other file systems have also been affected.

generic/193       - output mismatch (see /root/xfstests-dev/results//generic/193.out.bad)
    --- tests/generic/193.out   2024-01-14 08:55:20.114082471 +0000
    +++ /root/xfstests-dev/results//generic/193.out.bad 2024-01-14 14:30:51.598725128 +0000
    @@ -45,10 +45,10 @@
     check that suid/sgid bits are cleared after successful truncate...
     with no exec perm
     before: -rwSr-Sr--
    -after:  -rw-r-Sr--
    +after:  -rw-r--r--
     with user exec perm
     before: -rwsr-Sr--
    ...
    (Run 'diff -u /root/xfstests-dev/tests/generic/193.out /root/xfstests-dev/results//generic/193.out.bad'  to see the entire diff)

It turned out that the test failed because the user "fsgqa" did not have the "fsgqa" group assigned.
After rectifying this, the test passed successfully.

But it is nowhere stated that this has to be that way.

README says only:
6. (optional) Create fsgqa test users and groups:

   $ sudo useradd -m fsgqa
   $ sudo useradd 123456-fsgqa
   $ sudo useradd fsgqa2
   $ sudo groupadd fsgqa

Just in case, users fsgqa and fsgqa2 want the groups fsgqa/fsgqa2 as their primary groups
to have all tests work as expected?

Thanks,
//richard

Re: fsgqa group membership?

[Zorro Lang]

On Sun, Jan 14, 2024 at 04:42:41PM +0100, Richard Weinberger wrote:
> Hi!
> 
> After migrating to a new test environment, I observed that generic/193 failed.
> Initially, I assumed it was a UBIFS regression, but it appears that all other file systems have also been affected.
> 
> generic/193       - output mismatch (see /root/xfstests-dev/results//generic/193.out.bad)
>     --- tests/generic/193.out   2024-01-14 08:55:20.114082471 +0000
>     +++ /root/xfstests-dev/results//generic/193.out.bad 2024-01-14 14:30:51.598725128 +0000
>     @@ -45,10 +45,10 @@
>      check that suid/sgid bits are cleared after successful truncate...
>      with no exec perm
>      before: -rwSr-Sr--
>     -after:  -rw-r-Sr--
>     +after:  -rw-r--r--

Hi Richard,

Thanks for reporting this issue. Not sure why you get this failure by checking
this output only.

>      with user exec perm
>      before: -rwsr-Sr--
>     ...
>     (Run 'diff -u /root/xfstests-dev/tests/generic/193.out /root/xfstests-dev/results//generic/193.out.bad'  to see the entire diff)
> 
> It turned out that the test failed because the user "fsgqa" did not have the "fsgqa" group assigned.
> After rectifying this, the test passed successfully.

OK, so you've found out why it's failed :)

> 
> But it is nowhere stated that this has to be that way.
> 
> README says only:
> 6. (optional) Create fsgqa test users and groups:
> 
>    $ sudo useradd -m fsgqa
>    $ sudo useradd 123456-fsgqa
>    $ sudo useradd fsgqa2
>    $ sudo groupadd fsgqa
> 
> Just in case, users fsgqa and fsgqa2 want the groups fsgqa/fsgqa2 as their primary groups
> to have all tests work as expected?

Actually above steps aren't exact enough. It depends on a default behavior
of useradd command -- "By default, a group will also be created for the
new user" (from `man useradd`)

And according to the manual:

       -g, --gid GROUP
           The name or the number of the user's primary group. The group name must exist. A group number must refer to an already existing group.

           If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB variable in /etc/login.defs. If this variable is set to yes (or -U/--user-group is specified on
           the command line), a group will be created for the user, with the same name as her loginname. If the variable is set to no (or -N/--no-user-group is specified on the command
           line), useradd will set the primary group of the new user to the value specified by the GROUP variable in /etc/default/useradd, or 1000 by default.

You said "After migrating to a new test environment", I don't know what's
your new test env. Maybe your USERGROUPS_ENAB isn't set to yes by default,
or your useradd has an alias "useradd -N", or any other reasons.

Anyway if you hope to make sure each fsgqa users is assigned to their
own group, how about:

$ groupadd fsgqa
$ useradd -m -g fsgqa fsgqa
$ groupadd fsgqa2
$ useradd -g fsgqa2 fsgqa2
$ groupadd 123456-fsgqa
$ useradd -g 123456-fsgqa 123456-fsgqa

Or
$ useradd -U fsgqa
$ useradd -U fsgqa2
$ useradd -U 123456-fsgqa

Or other better ideas. Does that help? If so, we can think about changing
the doc description.

Thanks,
Zorro

> 
> Thanks,
> //richard
> 

Re: fsgqa group membership?

[Richard Weinberger]

Zorro,

----- Ursprüngliche Mail -----
>> It turned out that the test failed because the user "fsgqa" did not have the
>> "fsgqa" group assigned.
>> After rectifying this, the test passed successfully.
> 
> OK, so you've found out why it's failed :)

Yeah, but took me more time than it should. ;-)
 
>> 
>> But it is nowhere stated that this has to be that way.
>> 
>> README says only:
>> 6. (optional) Create fsgqa test users and groups:
>> 
>>    $ sudo useradd -m fsgqa
>>    $ sudo useradd 123456-fsgqa
>>    $ sudo useradd fsgqa2
>>    $ sudo groupadd fsgqa
>> 
>> Just in case, users fsgqa and fsgqa2 want the groups fsgqa/fsgqa2 as their
>> primary groups
>> to have all tests work as expected?
> 
> Actually above steps aren't exact enough. It depends on a default behavior
> of useradd command -- "By default, a group will also be created for the
> new user" (from `man useradd`)
> 
> And according to the manual:
> 
>       -g, --gid GROUP
>           The name or the number of the user's primary group. The group name must exist. A
>           group number must refer to an already existing group.
> 
>           If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB
>           variable in /etc/login.defs. If this variable is set to yes (or -U/--user-group
>           is specified on
>           the command line), a group will be created for the user, with the same name as
>           her loginname. If the variable is set to no (or -N/--no-user-group is specified
>           on the command
>           line), useradd will set the primary group of the new user to the value specified
>           by the GROUP variable in /etc/default/useradd, or 1000 by default.
> 
> You said "After migrating to a new test environment", I don't know what's
> your new test env. Maybe your USERGROUPS_ENAB isn't set to yes by default,
> or your useradd has an alias "useradd -N", or any other reasons.

SUSE Linux has traditionally not set USERGROUPS_ENAB, this explains the issue.
The old setup was not SUSE based.

> Anyway if you hope to make sure each fsgqa users is assigned to their
> own group, how about:
> 
> $ groupadd fsgqa
> $ useradd -m -g fsgqa fsgqa
> $ groupadd fsgqa2
> $ useradd -g fsgqa2 fsgqa2
> $ groupadd 123456-fsgqa
> $ useradd -g 123456-fsgqa 123456-fsgqa

Sounds good! It is verbose but that way everybody will know and it will work
on "strange" systems too.

Thanks,
//richard

Re: fsgqa group membership?

[Theodore Ts'o]

On Sun, Jan 14, 2024 at 04:42:41PM +0100, Richard Weinberger wrote:
> It turned out that the test failed because the user "fsgqa" did not
> have the "fsgqa" group assigned.  After rectifying this, the test
> passed successfully.
> 
> But it is nowhere stated that this has to be that way.
> 
> README says only:
> 6. (optional) Create fsgqa test users and groups:
> 
>    $ sudo useradd -m fsgqa
>    $ sudo useradd 123456-fsgqa
>    $ sudo useradd fsgqa2
>    $ sudo groupadd fsgqa

The useradd program creates the /etc/passwd entry as well as the
/etc/group entry.  Demonstration:

% kvm-xfstests shell
    ...
root@kvm-xfstests:~# grep foobarbaz /etc/passwd
root@kvm-xfstests:~# grep foobarbaz /etc/group
root@kvm-xfstests:~# useradd foobarbaz
root@kvm-xfstests:~# grep foobarbaz /etc/passwd
foobarbaz:x:31418:31418::/home/foobarbaz:/bin/sh
root@kvm-xfstests:~# grep foobarbaz /etc/group
foobarbaz:x:31418:

I don't know why that "sudo groupadd fsgqa" is in the README; it's not
necessary, and it would cause a "group already exists" error message.
For example:

root@kvm-xfstests:~# groupadd foobarbaz
groupadd: group 'foobarbaz' already exists

I did this demonstration using on a Debian-based test appliance.  But
it looks like Fedora's "useradd" works exactly the same way.  See the
web page here:

https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/basic-system-configuration/Managing_Users_and_Groups/

						- Ted

Re: fsgqa group membership?

[Zorro Lang]

On Sun, Jan 14, 2024 at 09:48:53PM +0100, Richard Weinberger wrote:
> Zorro,
> 
> ----- Ursprüngliche Mail -----
> >> It turned out that the test failed because the user "fsgqa" did not have the
> >> "fsgqa" group assigned.
> >> After rectifying this, the test passed successfully.
> > 
> > OK, so you've found out why it's failed :)
> 
> Yeah, but took me more time than it should. ;-)
>  
> >> 
> >> But it is nowhere stated that this has to be that way.
> >> 
> >> README says only:
> >> 6. (optional) Create fsgqa test users and groups:
> >> 
> >>    $ sudo useradd -m fsgqa
> >>    $ sudo useradd 123456-fsgqa
> >>    $ sudo useradd fsgqa2
> >>    $ sudo groupadd fsgqa
> >> 
> >> Just in case, users fsgqa and fsgqa2 want the groups fsgqa/fsgqa2 as their
> >> primary groups
> >> to have all tests work as expected?
> > 
> > Actually above steps aren't exact enough. It depends on a default behavior
> > of useradd command -- "By default, a group will also be created for the
> > new user" (from `man useradd`)
> > 
> > And according to the manual:
> > 
> >       -g, --gid GROUP
> >           The name or the number of the user's primary group. The group name must exist. A
> >           group number must refer to an already existing group.
> > 
> >           If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB
> >           variable in /etc/login.defs. If this variable is set to yes (or -U/--user-group
> >           is specified on
> >           the command line), a group will be created for the user, with the same name as
> >           her loginname. If the variable is set to no (or -N/--no-user-group is specified
> >           on the command
> >           line), useradd will set the primary group of the new user to the value specified
> >           by the GROUP variable in /etc/default/useradd, or 1000 by default.
> > 
> > You said "After migrating to a new test environment", I don't know what's
> > your new test env. Maybe your USERGROUPS_ENAB isn't set to yes by default,
> > or your useradd has an alias "useradd -N", or any other reasons.
> 
> SUSE Linux has traditionally not set USERGROUPS_ENAB, this explains the issue.
> The old setup was not SUSE based.

Thanks for this information!

> 
> > Anyway if you hope to make sure each fsgqa users is assigned to their
> > own group, how about:
> > 
> > $ groupadd fsgqa
> > $ useradd -m -g fsgqa fsgqa
> > $ groupadd fsgqa2
> > $ useradd -g fsgqa2 fsgqa2
> > $ groupadd 123456-fsgqa
> > $ useradd -g 123456-fsgqa 123456-fsgqa
> 
> Sounds good! It is verbose but that way everybody will know and it will work
> on "strange" systems too.

I'll send a patch to change that. Or you can do that too if you'd like, and feel
free to tell us if you find more fstests' issues.

Thanks,
Zorro

> 
> Thanks,
> //richard
> 

Re: fsgqa group membership?

[Richard Weinberger]

Ted,

----- Ursprüngliche Mail -----
> Von: "tytso" <tytso@mit.edu>
> The useradd program creates the /etc/passwd entry as well as the
> /etc/group entry.  Demonstration:
> 
> % kvm-xfstests shell
>    ...
> root@kvm-xfstests:~# grep foobarbaz /etc/passwd
> root@kvm-xfstests:~# grep foobarbaz /etc/group
> root@kvm-xfstests:~# useradd foobarbaz
> root@kvm-xfstests:~# grep foobarbaz /etc/passwd
> foobarbaz:x:31418:31418::/home/foobarbaz:/bin/sh
> root@kvm-xfstests:~# grep foobarbaz /etc/group
> foobarbaz:x:31418:

Only on systems with USERGROUPS_ENAB enabled in /etc/login.defs.

I happen to be on SUSE Linux which has traditionally no user groups.
...just sent a patch for generic/193 to detect this scenario.

Thanks,
//richard

Re: fsgqa group membership?

[Zorro Lang]

On Sun, Jan 14, 2024 at 09:57:06PM -0500, Theodore Ts'o wrote:
> On Sun, Jan 14, 2024 at 04:42:41PM +0100, Richard Weinberger wrote:
> > It turned out that the test failed because the user "fsgqa" did not
> > have the "fsgqa" group assigned.  After rectifying this, the test
> > passed successfully.
> > 
> > But it is nowhere stated that this has to be that way.
> > 
> > README says only:
> > 6. (optional) Create fsgqa test users and groups:
> > 
> >    $ sudo useradd -m fsgqa
> >    $ sudo useradd 123456-fsgqa
> >    $ sudo useradd fsgqa2
> >    $ sudo groupadd fsgqa
> 
> The useradd program creates the /etc/passwd entry as well as the
> /etc/group entry.  Demonstration:
> 
> % kvm-xfstests shell
>     ...
> root@kvm-xfstests:~# grep foobarbaz /etc/passwd
> root@kvm-xfstests:~# grep foobarbaz /etc/group
> root@kvm-xfstests:~# useradd foobarbaz
> root@kvm-xfstests:~# grep foobarbaz /etc/passwd
> foobarbaz:x:31418:31418::/home/foobarbaz:/bin/sh
> root@kvm-xfstests:~# grep foobarbaz /etc/group
> foobarbaz:x:31418:
> 
> I don't know why that "sudo groupadd fsgqa" is in the README; it's not
> necessary, and it would cause a "group already exists" error message.
> For example:
> 
> root@kvm-xfstests:~# groupadd foobarbaz
> groupadd: group 'foobarbaz' already exists

Hi Ted,

Yes, it'll fail as this, if USERGROUPS_ENAB is "yes" in /etc/login.defs.
That steps aren't correct 100%. I'll update this part description :)

Thanks,
Zorro

> 
> I did this demonstration using on a Debian-based test appliance.  But
> it looks like Fedora's "useradd" works exactly the same way.  See the
> web page here:
> 
> https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/basic-system-configuration/Managing_Users_and_Groups/
> 
> 						- Ted
>