cpu-users

[Cpu-users] Group Changes and CPU 1.4.1-RC1

[Blake M. <bma...@pu...>]

CPU 1.4.1-RC1 is available at:
http://cpu.sourceforge.net/cpu-1.4.1-RC1.tar.gz
  and
http://cpu.sourceforge.net/cpu-1.4.1-RC1.tar.bz2

There have been several major changes made in terms of the behavior of cpu.
These include:
 - Refuse to add or modify users whose supplementary groups (or supplied
   primary groups) do not exist. This is the same behavior as the GNU
   shadowutils
 - When a user is deleted they are now automatically removed from any
   secondary groups they were in (same as shadow-utils).
 - When a users secondary groups are modified, they are removed from all old
   secondary groups and added to new secondary groups (same as shadow-utils).
 - When a users primary group is changed they are no longer added to that
   group via a memberUid (same as shadow-utils).
 - Refuse to perform a groupdel if the group is a users primary group. This is
   the default behavior of the shadow-utils. However, the shadow-utils allow
   the group id to be changed even if it is a users primary group. I think
   this is wrong, but cpu does the same thing. Should it?
 - Allow violation of POSIX naming conventions (for use with Samba) by
   specifying the -o switch

I would appreciate feedback if people think any of the above behaviors are
incorrect. The other thing I have been thinking about, is what the behavior
should be when a user is added and -g is not explicitly set. Should a group be
generated with the same name as the user, and make the users primary group
that? Should there be a setting in the configuration file that specifies a
default group?

As always, feedback (and bug-reports) are appreciated.

-Blake

-- 
Blake Matheny           "... one of the main causes of the fall of the
bma...@pu...      Roman Empire was that, lacking zero, they had
http://www.mkfifo.net    no way to indicate successful termination of
http://ovmj.org/GNUnet/  their C programs." --Robert Firth

[Cpu-users] Group Changes and CPU 1.4.1-RC1

[Blake M. <bma...@pu...>]

CPU 1.4.1-RC1 is available at:
http://cpu.sourceforge.net/cpu-1.4.1-RC1.tar.gz
  and
http://cpu.sourceforge.net/cpu-1.4.1-RC1.tar.bz2

There have been several major changes made in terms of the behavior of cpu.
These include:
 - Refuse to add or modify users whose supplementary groups (or supplied
   primary groups) do not exist. This is the same behavior as the GNU
   shadowutils
 - When a user is deleted they are now automatically removed from any
   secondary groups they were in (same as shadow-utils).
 - When a users secondary groups are modified, they are removed from all old
   secondary groups and added to new secondary groups (same as shadow-utils).
 - When a users primary group is changed they are no longer added to that
   group via a memberUid (same as shadow-utils).
 - Refuse to perform a groupdel if the group is a users primary group. This is
   the default behavior of the shadow-utils. However, the shadow-utils allow
   the group id to be changed even if it is a users primary group. I think
   this is wrong, but cpu does the same thing. Should it?
 - Allow violation of POSIX naming conventions (for use with Samba) by
   specifying the -o switch

I would appreciate feedback if people think any of the above behaviors are
incorrect. The other thing I have been thinking about, is what the behavior
should be when a user is added and -g is not explicitly set. Should a group be
generated with the same name as the user, and make the users primary group
that? Should there be a setting in the configuration file that specifies a
default group?

As always, feedback (and bug-reports) are appreciated.

-Blake

-- 
Blake Matheny           "... one of the main causes of the fall of the
bma...@pu...      Roman Empire was that, lacking zero, they had
http://www.mkfifo.net    no way to indicate successful termination of
http://ovmj.org/GNUnet/  their C programs." --Robert Firth

Re: [Cpu-users] Group Changes and CPU 1.4.1-RC1

[Lukas K. <lu...@kn...>]

Am Fr, 2003-09-19 um 13.52 schrieb Blake Matheny:

Hi!

Congrats in making cpu behave more like it's GNU equivalents. I tried to
test it right away, but somehow my testing-slapd died away (I'll try
again later).


>  - Allow violation of POSIX naming conventions (for use with Samba) by
>    specifying the -o switch

Thank you for this, again :)

> I would appreciate feedback if people think any of the above behaviors are
> incorrect. The other thing I have been thinking about, is what the behavior
> should be when a user is added and -g is not explicitly set. Should a group be
> generated with the same name as the user, and make the users primary group
> that? Should there be a setting in the configuration file that specifies a
> default group?

In Debian, there is /etc/adduser.conf, which contains

--- snip ---
# The USERGROUPS variable can be either "yes" or "no".  If "yes" each
# created user will be given their own group to use as a default, and
# their home directories will be g+s.  If "no", each created user will
# be placed in the group whose gid is USERS_GID (see below).
USERGROUPS=yes
                                                                                
# If USERGROUPS is "no", then USERS_GID should be the GID of the group
# `users' (or the equivalent group) on your system.
USERS_GID=100
--- snap ---

I would suggest to do it in a similar manner, so that the user can make
the choice. For example, AFAIR the default on SuSE-Linux is to have a
group 'users' set to every user's primary group, while the default in
Debian is to give each user his own group with uid=gid.


> As always, feedback (and bug-reports) are appreciated.
> 
> -Blake

-- 
bye
  Lukas

Re: [Cpu-users] Group Changes and CPU 1.4.1-RC1

[Blake M. <bma...@pu...>]

This is implemented in CVS. Thanks for the suggestion. I'm in the process of
writing some regression tests with DejaGnu which will likely be the last bit
to go into 1.4.1 unless there are bug reports.

-Blake

Whatchu talkin' 'bout, Willis?
>
> ...snip... 
> 
> In Debian, there is /etc/adduser.conf, which contains
> 
> --- snip ---
> # The USERGROUPS variable can be either "yes" or "no".  If "yes" each
> # created user will be given their own group to use as a default, and
> # their home directories will be g+s.  If "no", each created user will
> # be placed in the group whose gid is USERS_GID (see below).
> USERGROUPS=yes
>                                                                                 
> # If USERGROUPS is "no", then USERS_GID should be the GID of the group
> # `users' (or the equivalent group) on your system.
> USERS_GID=100
> --- snap ---
> 
> I would suggest to do it in a similar manner, so that the user can make
> the choice. For example, AFAIR the default on SuSE-Linux is to have a
> group 'users' set to every user's primary group, while the default in
> Debian is to give each user his own group with uid=gid.
> 
> ...snip... 
>

-- 
Blake Matheny           "... one of the main causes of the fall of the
bma...@pu...      Roman Empire was that, lacking zero, they had
http://www.mkfifo.net    no way to indicate successful termination of
http://ovmj.org/GNUnet/  their C programs." --Robert Firth