From: Bela Lubkin <belal@sco.COM>
Subject: Re: /bin/su root ???
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Thu, 13 Aug 1992 18:25:00 GMT
Precedence: bulk

Jean-Pierre Radley wrote:

> /etc/authckrc contains these lines.
> 
> /bin/su root -c "/tcb/bin/authck -p $AUTHCKFLG $AUTHCKOUT"
> /bin/su root -c "/tcb/bin/authck -s $AUTHCKFLG $AUTHCKOUT"
> /bin/su root -c "/tcb/bin/ttyupd $AUTHCKOUT"
> 
> I searched them out because they were producing "ambiguous output redirect"
> messages at boot time. I have /bin/csh in root's passwd entry.
>
> I fixed the script to accomodate csh syntax (NBD), but my question is:

Before I get to the question: I, and SCO, highly recommend against
setting root's shell to /bin/csh.  You've dealt with some of the
consequences, but there may be several other less obvious ones.  For
instance, if you are running 3.2v2, you may now observe that your mount
table is trashed?  I recommend instead making an alternate /etc/passwd
entry called "rootcsh", with UID 0 and /bin/csh for shell.  I use
"rootksh" on my machine.  Attached below is a document on this.

> In a script, and particularly one that is not meant to be run interactively,
> but is part of the boot process, what exactly is accomplished by using
> "bin/su root"? If you aren't root when you call such a script ("you" being
> you at the keyboard, or cron, or the boot/init dance) then the script would
> stop cold at such a command, since a password sentry will bar the way.
> 
> So if you're already root, which enables you to skip merrily along when you
> encounter "su any_user_at_all", why call "su root"?  Just to show that you
> have PIDs to spare?

It's because of SCO's C2 implementation.  A process running from init
(such as these boot processes) has no login UID (LUID).  Without an
LUID, a process is not allowed to run setuid binaries.  One of the
functions of /bin/su is to set the processes' LUID.  The startup scripts
use it to ensure they will be able to run any suid binaries that get
called.

(/bin/su itself is suid.  I've never figured out how it is that it, but
no other suid binary, can be run by an LUID-less process).

>Bela<

=============================================================================

I want to use either the C or Korn shell as root; create an alternate root user.

RELEASE:  SCO UNIX System V/386 Operating System Generic
          Open Desktop Generic

PROBLEM:  How do I set up a root csh or ksh account under SCO UNIX System V/386
	  or Open Desktop?  I want to use either the "C" or Korn shell as root.

CAUSE:	  By default, the "root" login uses the standard Bourne shell,
          /bin/sh.  This is in fact necessary for correct system operation;
          the default shell of the "root" login must not be changed.
          Changing it can lead to mysterious "Bad Hertz Value" messages
          from programs such as df(C) and mount(C) and may have more
          serious consequences.

SOLUTION: It is not difficult to create an alternate root login that uses the 
	  shell of your choice.  It is necessary to use a user name other than 
	  "root" because some components of the system require the "root" 
	  login to use the Bourne shell.

	  The following steps can be used to create multiple or alternate
	  users of any type, or multiple users with different shells.


          The steps to create a C or Korn shell root login are simple, but
          it is recommended that you perform them after a complete system
          backup, in case anything goes wrong.

          In the example, accounts named "rootcsh" and "rootksh" will be
          created.  Note that it is your responsibility to set up the login
          environment using .cshrc or .kshrc files; no such files will be
          created automatically.  When setting up the Korn shell, be sure
          not to make changes to /.profile which would markedly change the
          environment of "root".

          The steps involve directly editing /etc/passwd and the protected
          password database.  Because of this, they MUST be performed from
          System Maintenance (single-user) mode.  Before beginning, shut
          down the system with shutdown(ADM); reboot and enter the root
          password to enter System Maintenance Mode.

          First, new protected password database entries must be created
          for the new accounts.  Start by copying root's entry:

            # cd /tcb/files/auth
            # cp r/root r/rootcsh
            # cp r/root r/rootksh

          If you want to use different user name(s), be sure to create the
          files in the correct subdirectory of /tcb/files/auth, corresponding 
	  to the first letter of the chosen user name.

          Now edit the new entries as follows: 
	  
	  Find each occurrence of the name "root" and replace it with the new 
	  name, EXCEPT the item "u_type=root".  "u_type=root" does not refer 
	  to the user name and must remain the same.  Use vi(C) or the editor 
	  of your choice.  Do NOT use a word processor that uses special 
	  characters for formatting.  Be very careful not to change the format 
	  of the files in any way; change only the name entries.  If the 
	  format of these protected password files, or of /etc/passwd is 
	  damaged, you may not be able to log into the system at all.

          The default /tcb/files/auth/r/root file looks like this (Note:
          lines marked with '*' were split in order to fit on the page):

            root:u_name=root:u_id#0:\
*                   :u_type=root:u_owner=root:u_cmdpriv=audit,auth,backup,
		    cron,lp,mem,sysadmin,terminal,uucp:\
*                   :u_syspriv=configaudit,writeaudit,execsuid,nopromain,
		    chmodsugid,chown:\
                    :u_minchg#0:u_exp#0:u_life#0:\
                    :u_pswduser=root:u_pickpw:u_genpwd:u_restrict@:u_nullpwd@:\
                    :u_maxtries#0:u_lock@:chkent:

          An equivalent entry for a rootcsh account looks like this (in
          /tcb/files/auth/r/rootcsh):

            rootcsh:u_name=rootcsh:u_id#0:\
*                   :u_type=root:u_owner=rootcsh:u_cmdpriv=audit,auth,backup,
		    cron,lp,mem,sysadmin,terminal,uucp:\
*                   :u_syspriv=configaudit,writeaudit,execsuid,nopromain,
		    chmodsugid,chown:\
                    :u_minchg#0:u_exp#0:u_life#0:\
*                   :u_pswduser=rootcsh:u_pickpw:u_genpwd:u_restrict@:
		    u_nullpwd@:\
                    :u_maxtries#0:u_lock@:chkent:

          Next you need to edit /etc/passwd.  Find the "root" entry and make
          a copy of it for each new account.  Carefully change the user name 
	  of each entry from "root" to the new name.  Then change the shell 
	  field to the desired shell.  This is the last field of the record; 
	  it should currently either be blank or read "/bin/sh".  If it is 
	  blank, append "/bin/csh" or "/bin/ksh" AFTER the last colon (:) on 
	  the line.  If it reads "/bin/sh", just add the necessary "c" or 
	  "k".  (Note that the Korn shell is not available under SCO UNIX 
	  System V/386 Release 3.2 or Open Desktop Release 1.0.0).

          The default /etc/passwd entry for "root" looks like this:

            root:*:0:1:Superuser:/:

          After editing /etc/passwd, the "root" entry should be the
          same.  However, a new entry, such as the one that follows, 
	  should be present:

            root:*:0:1:Superuser:/:
            rootksh:*:0:1:Superuser account with Korn shell:/:/bin/ksh

          Remove the user and group map files; they will be re-created 
	  when the system is rebooted:

            # rm /etc/auth/system/pw_id_map /etc/auth/system/gr_id_map

          Finally, run sysadmsh(ADM).  Select Accounts -> User -> Examine
          and enter the name of the new account.  Choose "Privileges".  You
          must make a trivial change to the privileges and save them, in
          order to activate the changes made in the protected password
          database.  It is sufficient to add "lp" to the end of the
          Subsystem list.  Even though "lp" is already in the list,
          sysadmsh will be fooled into believing you have made a change.
          It will then ask if you wish to have the modification take
          effect.  Enter yes.  Now choose "Identity".  Move to the Groups
          list and enter all the groups in which "root" is a member.  (You 
	  may use sysadmsh to examine the "root" account, or you may use the 
	  command "grep root /etc/group".)

          You can now reboot the system and log in as "rootcsh", "rootksh"
          or whatever account you have created.  Remember, as always, to be
          very careful when you are running with root privileges and to do
          so only when it is necessary for system maintenance tasks.

          NOTE:  Be aware that the passwords for the different "root" 
	  accounts will be distinct.  They will start out the same 
	  because the new accounts' protected password entries will 
	  have been duplicated from "root".  But when you change root's 
	  password as part of your regular security measures, be sure to 
	  change the other accounts' passwords as well. In order to change
          the password for the rootksh user, log in as rootksh and then 
          enter "passwd rootksh". Simply entering "passwd" is not sufficient.
          Similarly, enter "passwd rootcsh" for the rootcsh user. 
          It is probably safest to use the same password for all root accounts 
          since breaking into any one of them completely compromises system 
	  security; there is no point in having several different strings 
	  which a potential troublemaker might be able to guess.