riddle@woton.UUCP (Prentiss Riddle ) (07/13/87)
I am looking for some advice about the preferred way to temporarily
disable all user logins under System V. What I want is something
analogous to the BSD "/etc/nologin" file (or is that what it's really
called? I can't remember): I want to run in multi-user mode but allow
only root to log in. Furthermore, I want a simple, reversible solution
that can be run by the person who comes in on weekends to do our
backups.
The first thing that occurs to me is to whip up a shell script to copy
/etc/passwd to a safe place, then substitute a modified version of it
in which an '*' has been inserted in the password field of every login
except for root. Running the same script with a flag would reverse the
process. Obviously this script would have to be *highly* reliable.
Has anyone by any chance written such a script which they know has been
working for some time with no problems?
Another alternative would be to do the same sort of script, but have it
install an altered version of /etc/inittab instead of /etc/passwd, thus
disabling logins on all lines but /dev/console. That might be safer, I
guess (or would it be?).
Am I missing something? Is there a more straightforward approach? (We
are running System V Release 2.1.1 Version 1 on a 3B15, if it matters.)
--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
--- Opinions expressed are not necessarily those of Shriners Burns Institute.
--- riddle@woton.UUCP {ihnp4,harvard,seismo}!ut-sally!im4u!woton!riddletim@ora.UUCP (Tim O'Reilly) (07/14/87)
In article <905@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes: > I am looking for some advice about the preferred way to temporarily > disable all user logins under System V. > ...I want a simple, reversible solution > that can be run by the person who comes in on weekends to do our > backups. In /etc/inittab, the second field describes the "run level" at which a serial line will have a getty. Run level settings for normal multi-user use are 2 and 3. (Two different levels are available so you can temporarily disable getty on a port for dialin/dialout use by cu and uucp.) 6 can be used as a run level for multi-user administrative work. The point is that by specifying only certain run levels in a tty entry, and then changing the run level with init, you can control whether or not there's a getty on that tty. For example, with the entries: 000:236:respawn:/etc/getty tty000 9600 001:23:respawn:/etc/getty tty000 9600 002:2:respawn:/etc/getty tty000 9600 You can type: # init 6 and only tty000 will have a getty. Type: # init 3 and tty002 will be without one (for dialout by uucp or cu). -- LIVE: Tim O'Reilly (617) 527-4210 USPS: O'Reilly & Associates, Inc., 981 Chestnut Street, Newton, MA 02164 UUCP: seismo!uunet!ora!tim ARPA: tim@ora.uu.net
philip@axis.fr (Philip Peake) (07/15/87)
In article <905@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes: > I am looking for some advice about the preferred way to temporarily > disable all user logins under System V. What I want is something > analogous to the BSD "/etc/nologin" file (or is that what it's really > called? I can't remember): I want to run in multi-user mode but allow > only root to log in. Furthermore, I want a simple, reversible solution > that can be run by the person who comes in on weekends to do our > backups. The easiest way that I can think of is to use /etc/profile. Its much less dangerous than playing with /etc/passwd or /etc/inittab. Just include the following in your /etc/profile: if [ -f /etc/nologin ] then . /etc/nologin fi Inside the file /etc/nologin you put whatever you want, such as: case $LOGNAME in root) ;; *) echo "Sorry, logins are disabled" exit ;; esac The only real disadvantage to this scheme is that they will have actually logged in before being thrown off again. But is the reason for doing this is simply to allow uninterupted backups, then it will do. You could also put a little message into /etc/issue to tell them that it is not worth the effort of trying to login. Philip
wcs@ho95e.ATT.COM (Bill.Stewart) (07/16/87)
In article <905@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes:
: I am looking for some advice about the preferred way to temporarily
: disable all user logins under System V.
: ...I want a simple, reversible solution
: that can be run by the person who comes in on weekends to do our
: backups.
Sounds like you've got two problems: how to keep people from logging in, and
what to do about programs already running. The latter is hard to do well
(if you kill them, you have to notify the users, and hope they don't mind.)
The "fuser" command is one way to kill off processes.
For users who use /bin/sh or ksh, you can put the following in /etc/profile:
if [ -f /etc/nologin -a "$LOGNAME" != "root" ]
then echo "Sorry, the system is not available" ; exit
fi
You've also got to turn off incoming uucp; you could chmod 0 uucico or
something. (If you're not backing up /usr, and you're restricting uucp
permissions, you could just leave it on.)
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcsguy%gorodish@Sun.COM (Guy Harris) (07/16/87)
> The easiest way that I can think of is to use /etc/profile.
Unless, of course, you have users with login shells other than
"/bin/sh" (say, for example, "/usr/lib/uucp/uucico", or some special
application).
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.comkimcm@olamb.UUCP (Kim Chr. Madsen) (07/16/87)
In article <256@axis.fr>, philip@axis.fr (Philip Peake) writes: > In article <905@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes: > > I am looking for some advice about the preferred way to temporarily > > disable all user logins under System V. What I want is something > > analogous to the BSD "/etc/nologin" file. > The easiest way that I can think of is to use /etc/profile. > Its much less dangerous than playing with /etc/passwd or > /etc/inittab. Except that it will not allways work - user's who are not running the /bin/sh or other shells that don't source the /etc/profile will not be hindered by this approach... The best way to do it is to use the init program to change the state of the system - use "init s" to go to single user-mode mount the /usr and other disks/partions you want to backup - do your backup and return to multiuser state again by calling "init 2". If you don't like this approach because you want to be able to login as a non-root account (or whatever reason) you can maintain two password files and have a shell-script switching between them when you change state to a user defined state (don't use init state 3 - it is used for network in SYSV release 3.0 and later, but use state 4) put the shell script in the directory /etc/rc4.d/ and return to state 2 when you're done with the backup. If you use the latter method remember to kill active user processes (if necessary) with the command /etc/killall - and don't forget to issue a warning to all users so they can log off the system gracefully before you'll have to kill them! Finally if you have the sources for /bin/login you can hack it to check whether /etc/nologin exists and if so prevent further logins. Kim Chr. Madsen.
randy@chinet.UUCP (Randy Suess) (07/17/87)
In article <905@woton.UUCP> riddle@woton.UUCP writes: >I am looking for some advice about the preferred way to temporarily >disable all user logins under System V. What I want is something >analogous to the BSD "/etc/nologin" file (or is that what it's really A friend of mine wrote a /bin/login from scratch that implements the /etc/nologin feature. I use it on my 3b2 to do just what you are asking for. It also implements the /etc/issue, chroot logins and some other niceties. Available for the emailing.. -- that's the biz, sweetheart..... Randy Suess ..!ihnp4!chinet!randy
kai@ihlpa.ATT.COM (Irwin) (07/18/87)
In article <905@woton.UUCP>, riddle@woton.UUCP writes: > I am looking for some advice about the preferred way to temporarily > disable all user logins under System V. What I want is something > analogous to the BSD "/etc/nologin" file (or is that what it's really > called? I can't remember): I want to run in multi-user mode but allow > only root to log in. Furthermore, I want a simple, reversible solution > that can be run by the person who comes in on weekends to do our > backups. > > The first thing that occurs to me is to whip up a shell script to copy > /etc/passwd to a safe place, then substitute a modified version of it > in which an '*' has been inserted in the password field of every login > except for root. Running the same script with a flag would reverse the > process. Obviously this script would have to be *highly* reliable. > Has anyone by any chance written such a script which they know has been > working for some time with no problems? > > Another alternative would be to do the same sort of script, but have it > install an altered version of /etc/inittab instead of /etc/passwd, thus > disabling logins on all lines but /dev/console. That might be safer, I > guess (or would it be?). > > Am I missing something? Is there a more straightforward approach? (We > are running System V Release 2.1.1 Version 1 on a 3B15, if it matters.) > > --- Prentiss Riddle ("Aprendiz de todo, maestro de nada.") > --- Opinions expressed are not necessarily those of Shriners Burns Institute. > --- riddle@woton.UUCP {ihnp4,harvard,seismo}!ut-sally!im4u!woton!riddle If you've ever delt with a 3B15 (or 3B5) with a hosed passwd file, I dout you'd be to quick to play around with this, Its a real pain in the !#$! If you only play around with the last half of inittab you are relitively safe (after the console gets respawned). I've delt with this problem alot and have used several solutions including the /etc/inittab one (passwd one seemed a tad risky especially if the initdefault is set to multi user) anyway two SAFE solutions to the problem are: 1) a login id screener placed in /etc/profile that screens the logins and only lets root on. Since root is console bound as a primary login this solves the problem. Could be somthing like: if test LOGNAME != root then echo "Machine not available for general use, sorry" exit fi this not only locks out other terminals but other login ids as well. 2) if the intent is just to lock out other terminals than you can define another init level that is multi user but console only so in inittab you would define ports as: co:1234:respawn:/etc/getty console console ct:2:respawn:/etc/getty contty contty 001:2:respawn:/etc/getty tty001 9600 so that console would be respawned at init level 3 and 4 and other ports would not, you can also only turn on SOME ports allowing say hardwired access but not dial-up access. So when you came up to init level 2 you would just go to init level 3 or 4 for the disired system configuration. (Note on a 3b15 these (3 and 4) are the only 2 available "user defineable init levels" 1 is single user mode, 2 is multi user, 5 is firmware, and 6 is system reboot) I hope this helps I've used both (actually the first one to only allow "machine" access (ie:nuucp only) on certain ports to control network traffic) and the second for stand alone performance testing. Ken A. Irwin AT&T Bell Labs, Naperville IHP 1A332 (312) 416-4485
kai@ihlpa.ATT.COM (Irwin) (07/18/87)
In article <632@ora.UUCP>, tim@ora.UUCP writes: > In article <905@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes: > > I am looking for some advice about the preferred way to temporarily > > disable all user logins under System V. > > In /etc/inittab, the second field describes the "run level" > at which a serial line will have a getty. Run level > settings for normal multi-user use are 2 and 3. (Two > different levels are available so you can temporarily > disable getty on a port for dialin/dialout use by cu and > uucp.) 6 can be used as a run level for multi-user > administrative work. > true, level 3 CAN be used for that, but this is a user defined run level and can be used for anything. BUT the machine in question is a 3B15 in which run level 6 is equivelent to INIT 0 (halt) and then boots to the specified initdefault, this is off limits on a 3B15! This is not ment to be a flame just informational. And just for the record init level 5 is also off limits on a 15 (this is firmware mode) Ken A. Irwin AT&T Bell Labs, Naperville IHP 1A332 (312) 416-4485
arosen@eagle.CS.ULowell.Edu (Andy Rosen) (07/18/87)
In article <1309@chinet.UUCP> randy@chinet.UUCP (Randy Suess) writes: >In article <905@woton.UUCP> riddle@woton.UUCP writes: >>I am looking for some advice about the preferred way to temporarily >>disable all user logins under System V. What I want is something >>analogous to the BSD "/etc/nologin" file (or is that what it's really > > A friend of mine wrote a /bin/login from scratch that implements >the /etc/nologin feature. This is the best solution I've seen so far. It will work whatever shell a user has, and you don't need source. A simple test in login.c like if ((pwd->pw_uid != 0) && ((fp = fopen("/etc/nologin", "r")) == NULL)) will restrict logins to root if /etc/nologin is there. But, of course, you need source to do this. The solution I used, was to write a program that would be everyones login shell. It checks for nologins and such and then execs sh/csh [the method I use to decide which one is primitive, but serves the purpose for now]. The only problem I see coming out of this, are programs that use the pw_shell field of the passwd struct. Su is one, and this brings back the problem of needing source. Su was easy enough to rewrite around this, and I haven't found any others that broke. Still, a from-scratch login is the only full-proof way to do it. Andy Rosen | ulowell!arosen | ************* | "I got this guitar and I ULowell, Box #3031 | | * RD in '88 * | learned how to make it Lowell, Ma 01854 | | ************* | talk" -Thunder Road
hansen@pegasus.UUCP (Tony L. Hansen) (07/19/87)
< <In article <905@woton.UUCP> riddle@woton.UUCP writes:
< <<I am looking for some advice about the preferred way to temporarily
< <<disable all user logins under System V. What I want is something
< <<analogous to the BSD "/etc/nologin" file (or is that what it's really
< Still, a from-scratch login is the only full-proof way to do it.
(I waited a bit to see if anyone posted this solution to the above problem,
but no one has yet.)
The problem is actually simple to solve on a System V machine.
If both /etc/dialups and /etc/d_passwd exist, the System V /bin/login will
prompt for an additional password before letting a person it.
/etc/dialups contains a list of tty lines on which a second password is to
be prompted. If the tty being logged in on is listed in /etc/dialups, then
/bin/login will look through /etc/d_passwd for a shell which matches the
login shell to be used for that user. The other field on this line is the
password to prompt for (kept encrypted, of course). (If the shell being used
for the login is not found, the password used defaults to that specified on
the /bin/sh line.) If no password is listed on the appropriate line,
/bin/login will not prompt for a password (this is commonly used for
specifying /usr/lib/uucp/uucico as a login shell which does not require a
second password). The user types in a password, it is encrypted, and
compared with the second field of the /etc/d_passwd line which matched.
A normal site would do something like this for extra security:
$ ls /dev/tty* > /etc/dialups
$ cat > /etc/d_passwd
/usr/lib/uucp/uucico::
/bin/sh:WeJUkasdfjljs:
^D
$
This example lists all normal tty lines and requires all users, except for
uucp logins, to type in the extra site password.
As another example,
$ ls /dev/tty* > /etc/dialups
$ cat > /etc/d_passwd
/bin/sh:*:
^D
$
This says to require logins on all tty lines to prompt for the extra
password. (Since the console won't be in the list, there will be no trouble
logging in from the console.) And since '*' can never be the result of an
encryption, no one else will be able to log in.
Create the /etc/dialups file. As long as /etc/d_passwd doesn't exist, it
won't do any harm. Then for your backup script, all it has to do is move a
file into /etc/d_passwd when it's time to block off all logins. When it's
time to turn things back on again, /etc/d_passwd would be moved out of the
way.
Tony Hansen
ihnp4!pegasus!hansen
attmail!tonyrobertd@ncoast.UUCP (Rob DeMarco) (07/20/87)
905@woton sugests....
[ Make a copy of /etc/passwd and put an asteric in all the passwords except
root ]
Am I missing something here? To me, it just seems simpler to make a copy
of the file. Then clear the password file except for the root password. ( you
may wish to clear the passwd file after making the copy and include a grep
which finds user root and puts him safely in the file. A flag would then move
the backup file and replace the password file. This seems to be an ok aproach -
am I missing something?
[> Rd
--
North Coast Computer Resources(ncoast)
UUCP:decvax!cwruecmp!ncoast!robertd
Sysop: NEODG (login "sbbs")davel@hpisoa1.HP.COM (Dave Lennert) (07/21/87)
> In article <905@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes: > > I am looking for some advice about the preferred way to temporarily > > disable all user logins under System V. > > ...I want a simple, reversible solution > > that can be run by the person who comes in on weekends to do our > > backups. > > In /etc/inittab, ... Keep in mind that disabling gettys via /etc/inittab does not disable logins on ptys via rlogin. (SOME System V systems support rlogin...) -Dave Lennert HP ihnp4!hplabs!hpda!davel
rwhite@nu3b2.UUCP (Robert C. White Jr.) (07/25/87)
> < <In article <905@woton.UUCP> riddle@woton.UUCP writes: > < <<I am looking for some advice about the preferred way to temporarily > < <<disable all user logins under System V. What I want is something > < <<analogous to the BSD "/etc/nologin" file (or is that what it's really > < Still, a from-scratch login is the only full-proof way to do it. If you have a run state left [say 3 or 4] define the runstate to allow logins at the console only. Try adding a 3 after every 2 in the runstate field of every line that has a 2 in inittab execpt for the getty entries. Then "init 3" or "telinit 3" will turn off the logins and "init 2" or "telinit 2" will restore the login potental. If you are doing system adminstration functions "telinit s", "init s", "telinit 1", and "init 1" will terminate everything execpt the session at "/dev/syscon", init, and the swapper tasks, you may have to remount the user partition, but it IS secure for some reasons. All the "telinit" commands may be preformed from cron, but cron dies under "telinit 1" [... s ... etc] so the telinit to return to 2 MUST be part of any cron[ed] scripts. Robert. Disclaimer: My mind is so fragmented by random excursions into a wilderness of abstractions and incipient ideas that the practical purposes of the moment are often submerged in my consciousness and I don't know what I'm doing. [my employers certainly have no idea]