🚀 go-pugleaf

In article <BryC9r.Ksr@ux1.cso.uiuc.edu> lemson@ux1.cso.uiuc.edu (David Lemson)  
writes:
>  gungner@cs.ucla.edu (David Gungner) writes:
>  
>  >Does anybody know of a way to reconfigure UserManager so that a few
>  >non-root users (but they are in the group "wheel") can add new users?
>  >I want to grant a few maintenance people the ability to add new users
>  >without giving out the root password.
>  
>  Couple ways to do it:
>  Theoretically, if you make UserManager mode 4750, and make its group
>  'wheel', then anyone in wheel can run it and it should think that
>  you are root (it's setuid).  I haven't tried this, though.  It's
>  possible that this won't work, though (as a security precaution
>  inside UserManager).

UserManager is already set-uid root. It couldn't function if it were not.
So it is not possible, I think, to make it functional for the whole wheel
group. It would in fact enable anybody in the wheel group to go root by 
modifying the root account (removing the password, for instance) or
creating a user entry with 0:1 as its user and group number, effectively
creating another root entry. This is definitely not secure.

> Another way to do it would be to whip up a little perl script that
> takes userid, name, uid, password in from the user and then does a
> call to nu -A that creates users from the command line.  The perl
> script would have to be setuid.  That ought to work, too.
> (I say do a Perl script because it's more secure than a shell
> script - or put a C wrapper around a shell script and that would be
> OK too)
> 

Use a Perl script. A shell SUID script is not secure. A wrapper, if 
correctly done should be OK, but Perl is perfect for that kind of things.
What you want is a script that does the above, but with the following
restrictions:
- Do not allow modification of an existing account.
- Do not take the uid from the command line, but assign one (i.e. not
0 or any duplicate uid).
- Do not take a gid, but a list of groups you want the new user to belong to.
Once again, test and forbid all ``dangerous'' accounts, like wheel, staff,
daemon, sys, bin, uucp, kmem, news, tty, operator, ingres.
- Put any other restrictions you like so as not to rule over an anarchic 
system.

Like that it should work. However, if you do anything less than that, you 
might as well give the root passwd to the wheel people. It's less hassle. 

Lga.
---
                                       |"I don't know what it's called, but
Laurent Amon                           | we're doing one about going to see 
       e-mail: amon@cs.stanford.edu    | a wizard. Something about following
           lga@sandman.stanford.edu    | a yellow sick toad. (Moving Pictures)