Easy way/script to add another user like me?

[Alan McKinnon]

On Friday, 3 March 2006 21:56, Joe(theWordy)Philbrook wrote:
> It would appear that on Mar 3, Alan McKinnon did say:

<snip>

> > It's a two edged sword. You can make the root account very secure
> > by renaming the root username - it doesn't have to be root, you
> > can make it easterbunny and the kernel couldn't care less (it's
> > UID 0 that identifies root) and disallow superuser logins on all
> > terminals. Then a user must log in as himself and 'su -' which
> > leaves an audit trail
>
> Yeah, I've heard of that, but I've also heard that some software
> may fail if root isn't named root???

It's been a long time since I tried this (and even then it was mostly 
to demonstrate that the username is irrelevant, and the kernel uses 
the UID). And it won't help if the command is 'su -' anyway

It's a case of try it and see, and YMMV

> Ummnn, how does one disallow all superuser logins anyway???

Several places :-)

/etc/login.defs has a NOLOGIN_STR (which judging from the comments 
seems to not be implemented anymore) - make root's shell 
in /etc/passwd = NOLOGIN. /bin/false or /bin/nologin would do the 
same

/etc/securetty lists the tty's that root can log in on. 
/etc/security/access.conf gives some finer control, including using 
the wheel group to limit who can su to root

pam supercedes all these for many years now.
/etc/pam.d/login is worth a look

This all largely applies to tty logins. You should naturally set up 
gdm/kdm/xdm to disallow root logins. I've never bothered researching 
how to prevent a user opening an X terminal directly as root. The 
whole reason to do it on the tty is to login as yourself then su and 
get an audit trail. If an X server is running that first step was 
already accomplished.

> > The disadvantage is that there's no granularity. If any one knows
> > the password they can become root and the admin can't control
> > what they can do. Hence the valid need for sudo to limit what
> > other users can do. I believe a better option would have been for
> > sudo to require a strong *root* password, then elevate the user
> > to do only what sudoers allows him to. But, it wasn't implemented
> > that way.
>
> Yeah, I'd have liked that a little better... Though since the
> method they choose to prevent root logins was to disable the root
> password it would have to have been a special sudoer account
> password. This might have been a bit of work to set up.

It's probably a concession to having something that can work reliably 
out the box. Imagine telling your mother that it's real easy to be 
able to install new software (after doing a wizard-led install), all 
she has to do is edit the pam configuration...

<snip>

> > The intention is that the first user account should be your own.
> > If you set up the box, you are probably the person controlling it
> > and you most likely want yourself to be able to become root.
>
> It was exactly that assumption that made my non-conformist nature
> decide I wasn't going to use sudo at all in the first place.

A non-conformist admin using a non-conformist OS... You sure you don't 
use non-conformist hardware as well? Like maybe a ppc beowulf? :-)

> If I were to use sudo it would NEVER be the same account I
> routinely use to send and receive e-mail and or surf the web with
> that I would want given sudoer permission to... To me this is
> almost as bad as running as root all the time. as sooner or later
> one will fail to notice that someone was standing behind you when
> you login to your everyday login. which gives them a chance to
> watch you type your password...
>
> When I login to a root account I look behind me first... etc...

That's food for thought. I'll now have to amend the list of security 
practices I keep in my head.

sudo is a good choice for the average user's workstation. But as with 
all things the default choice might not be the best choice in a given 
situation,a nd nothing beats actually knowing what is going on

> Also in my case I routinely start up a new installation with a junk
> username with a VERY trivial password that I only use to test
> generic user permissions settings and to configure certain user
> preferences prior to copying the (dot)files to etc/skel before I
> ever create my own regular user, for which, incidentally, I insist
> on specifying the uid, So that files I own on one of my other
> distro's can be readily accessed as long as the partitions are
> mounted...

The person who solves that problem will be my hero for life. I have 
two distros on this machine (Breezy and a stable gentoo). I want the  
*same* apache/php/python/mysql/postgres thing to work seamlessly on 
both. I can't - user IDs differ. And there's no easy solution for 
system accounts that doesn't require continual manual intervention

<snip>

-- 
Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five