gfl@tuhold (Gerhard Fleischanderl) (09/29/88)
We want to restrict login-access at a specified terminal line to a group of designated users, with the other ttys still accessible to all users. Our machine is a VAX 11/750 running Ultrix 1.0. Is it possible to notify getty(8) or login(1) of a list of users who are granted login at the specified line? If no, are there alternatives to prevent users from coming in via a certain line? (Manipulating those users' .cshrc or .login files and forcing the login shell to kill itself if it comes up at the "denied" tty seems unsatisfactory.) I know of the "secure" option in Ultrix 2.x, but that would not be sufficient, either. We don't have a source licence, so we can't compile an enhanced getty or login. Thanks in advance for any suggestions. Gerhard Fleischanderl -- Institut f. Angewandte Informatik, Technical University Vienna, Austria -- paper-mail: Paniglgasse 16/181, A-1040 Vienna e-mail (UUCP): ...!mcvax!tuvie!tuhold!gfl
cdold@starfish.Convergent.COM (Clarence Dold) (09/30/88)
In article <1227@tuhold>, gfl@tuhold (Gerhard Fleischanderl) writes: > > We want to restrict login-access at a specified terminal line > to a group of designated users, with the other ttys still > accessible to all users. Even though it isn't documented, UNIX SysV 2.2 contains a dialup password feature, that can be invoked for certain lines, and selectively for certain login initial programs. Try strings /bin/login|grep passwd to see if your login is looking for d_passwd. If it is: /etc/dialups is a list of the ports you *might* want to block: # /etc/dialups will contain all of the devices that # **might** present Dialup Password, depending on # entries in /etc/d_passwd. /dev/tty023 /dev/tty024 /dev/tty025 /dev/tty026 /etc/d_passwd contains a description of the initial programs subject to password if they are invoked from one of the 'dialup' lines: /bin/jsh:XfCQ/Cu1tfd9g: /bin/sh:: /usr/bin/ksh:: # /etc/d_passwd contains all 'initial programs' allowed # when invoked on a line specified in /etc/dialups # A line to allow uucp entry with no password: /usr/lib/uucp/uucico:: # /bin/sh:13characterEncryption: # The encrypted password is drawn over via grep after applying # /bin/passwd to a superfluous entry in /etc/passwd. # Use links to different shell names to cause certain login ids # to require Dialup password, while other logins using the same # shell with a different name don't need a password. # In this example, restricted users show /bin/jsh as their shell # While the other users specify /bin/sh, actually linked. #-r-------- 1 root root 368 Nov 24 08:45 /etc/d_passwd #-r-------- 1 root root 189 Nov 24 08:46 /etc/dialups #-r-xr-xr-x 3 bin bin 45470 May 19 15:32 /bin/sh #-r-xr-xr-x 3 bin bin 45470 May 19 15:32 /bin/jsh -- --- Clarence A Dold - cdold@starfish.Convergent.COM (408) 435-5274 ...pyramid!ctnews!mitisft!professo!dold P.O.Box 6685, San Jose, CA 95150-6685
ed@mtxinu.UUCP (Ed Gould) (10/01/88)
>We want to restrict login-access at a specified terminal line >to a group of designated users, with the other ttys still >accessible to all users. >Our machine is a VAX 11/750 running Ultrix 1.0. >I know of the "secure" option in Ultrix 2.x, but that would not >be sufficient, either. The secure option may not be what you want here, but there is another approach, especially if you don't need to do anything fancy before reading the user's login name (like speed selection). The /etc/ttys file specifies the program to be run to capture the login name: typically /etc/getty. You can use any program of your own design instead, however. The functions of getty are, essentially, 1. set the line to the correct speed and modes, and 2. collect the user's login name, and exec login Even though you don't have source, writing a getty replacement shouldn't be too hard. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,uunet}!mtxinu!ed +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (10/02/88)
In article <659@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >>We want to restrict login-access at a specified terminal line >>to a group of designated users, with the other ttys still >>accessible to all users. > >The /etc/ttys file specifies the program to be run to capture the >login name: typically /etc/getty. You can use any program of your >own design instead, however. The functions of getty are, essentially, Unfortunately, Ed is not quite right here, because of the following: Getty: login: me: shap ...getty execs login... login: passwd: me: BOGUS (intentionally mistyped) *login*: login: A better place to enforce this sort of thing is to put in /etc/profile and /etc/.login a line to check the tty line against the users group, and log them out if the check fails. This doesn't involve writing any special code.
arosen@hawk.ulowell.edu (MFHorn) (10/03/88)
From article <659@mtxinu.UUCP>, by ed@mtxinu.UUCP (Ed Gould): >>We want to restrict login-access at a specified terminal line >>to a group of designated users, with the other ttys still >>accessible to all users. >>Our machine is a VAX 11/750 running Ultrix 1.0. > > The /etc/ttys file specifies the program to be run to capture the > login name: typically /etc/getty. You can use any program of your > own design instead, however. A simpler solution would be to add a group, foo, containing the users who will be using this line, and 'chmod 660 /dev/tty?? ; chgrp foo /dev/tty??'. It's very possible that Ultrix will do funny things to the permission on the tty after the user logs out, in which case you could run a two line program of your own on that line that does a chmod/chgrp and then exec's getty. We're not running 1.0 here, so I can't check. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be
george@rebel.UUCP (George M. Sipe) (10/04/88)
In article <1227@tuhold> gfl@tuhold (Gerhard Fleischanderl) writes: > >We want to restrict login-access at a specified terminal line >to a group of designated users, with the other ttys still >accessible to all users. Over the years I have seen this question asked again and again. I wanted to essentially do this and a few similar things myself. For example, I have a large number of UUCP links for 1 incomming modem line. It's necessary to 'partition' access to it or I'd need several more lines. Anyway, I wrote a program called access and have been using it for about a year. July 19th, I sent it to comp.sources.unix so that everyone who wanted it could use it. Well, it still hasn't been posted (I'm now considering sending it to comp.sources.misc). If it isn't posted soon, I'll find another route - althought it would benefit more people if it appeared in comp.sources.unix. The manual page follows, let me know what you think. .TH ACCESS l "19 June 1988" .SH NAME access \- limit system usage to specified ttys and times .SH SYNTAX .B "/usr/local/etc/access" .SH DESCRIPTION .I Access provides a simple yet powerful method of limiting user access to a system. Simply specify .B /usr/local/etc/access in place of a login shell in the password file for each user who is to have restricted accessibility to a system. .I Access will lookup that user's entry in the control file .B /usr/local/lib/access and execute the specified real login shell (with optional arguments) if the current tty and time falls within one or more of the access constraints given. .PP Each entry in the control file has the form: .PP userspec [constraint1] [...[-]o[r] constraintN] .br full_pathname [args] .PP Blank lines are ignored, while `#' marks the start of a comment which continues to the end of the line. Entries may be continued by indenting continuation lines with whitespace (blanks or tabs). Entries are limited to a maximum of 1k characters. .PP Accessibility constraints limit the tty port and/or up to 6 accessibility classes of time. Accessibility constraints are composed of multiple specifications separated by spaces and/or tabs. Additional constraints may be specified by connecting them with the .B OR operator (see below). .PP Each specification within an accessibility constraint is composed of a letter (optionally preceded by `-') followed by the specification. They are as follows: .PP .nf .ta 0.8i 1.6i 2.4i class range description ----- ----- ----------- `t' tty name restrictor `m' 0-59 minute restrictor `h' 0-23 hour restrictor `w' 0-6 day of week restrictor (0 = Sunday) `D' 1-31 day of month restrictor `M' 1-12 month restrictor `Y' 87-99 year restrictor `o[r]' logical OR separator .fi .PP Where an accessibility class is not specified within an accessibility constraint, no restriction will be applied to that class. For instance, if `m' does not appear within an accessibility constraint then accessibility will not be constrained by the current minute. .PP Numeric accessibility classes are specified with single values or a range of values separated by `-'. Multiple specifications may be given at one time separated by `,'. Any given class may appear more than once. The sense of any specific specification may be negated by `!' (or `^'). Further, `*' (or `@') may be used to indicate infinity. For example, each of the following are equivalent: "h0-23", "h*-23", "h0-*", "h*-*", "h*", "h0,1,2-10 h11-*". .PP The tty accessibility class is composed of one or more string segments, one of which must match the tail of the current tty's name. As with the numeric accessibility classes, "-,!^*@" are all supported. .PP The first entry in the control file, in which the current user's name is matched within the "userspec", will be the entry processed for that user. The "userspec" is composed of one or more full usernames, one of which must exactly match the current user's name. As with the numeric and tty accessibility classes, ",!^*@" are all supported. Note that ranges specified by `-' are NOT supported in the "userspec". .SH EXAMPLES joe h9-17 /bin/csh .IP "" 5 Allow `joe' access only between 9AM and 5PM. .PP uucp,net ttya7 w1-5 h*,!9-17 or ttya0-ab w0,6 .br /usr/lib/uucp/uucico .IP "" 5 Allow `uucp' and `net' access on (/dev/t)tya7 weekdays except between 9AM and 5PM .B or on (/dev/t)tya0 thru (/dev/tty)ab (anytime) on weekends. Note the "*" is required in the hour specification. Otherwise, since "h" appeared - hours would be constrained, no unrestricted hours specified, then further constrained to not be between 9 and 17. In other words no hour would be acceptable and only the second accessibility constraint could possibly pass. .PP *,!root Y*-87 t*,!console or M*-9 Y88 t*,!console /bin/sh .IP "" 5 Allow everyone access except `root' thru September 1988 on any tty except consoles. Note that if .I access is specified as `root's login shell as this example implies, then `root' must have an entry somewhere following this example entry. Alternately, `root' may have an entry before this one in which event the ",!root" would be extraneous since .I access would never get this far for user `root'. .PP uucp /usr/lib/uucp/uucico .br * /bin/csh .IP "" 5 Give `uucp' unrestricted access to `uucico' and everyone else unrestricted access to the `csh'. Effectively, .I access would not be doing anything. This would be one method of removing access constraints for everyone without changing the password file. .SH TESTING If .I access is invoked from a shell then the access constraints will be derived from its arguments (do not specify the `userspec'). In place of actually executing the real login shell specified, that program's name and its argument vector will be displayed. .SH INSTALLATION Be sure to disable users ability to change their login shell and thereby defeat this control. For example, "chmod o-x /usr/ucb/chsh". .SH "SEE ALSO" Files: /etc/passwd and /usr/local/lib/access .SH DIAGNOSTICS If at least one accessibility constraint passes, the presence of .I access is invisible. If no accessibility constraint passes, then a message is issued and the user immediately logged off. .SH AUTHOR George M. Sipe currently (7/88) at rebel!george -- George M. Sipe, Phone: (404) 662-1533 Tolerant Systems, 6961 Peachtree Industrial, Norcross, GA 30071 UUCP: ...!{decvax,hplabs,linus,rutgers,seismo}!gatech!rebel!george
bzs@xenna (Barry Shein) (10/06/88)
From: gfl@tuhold (Gerhard Fleischanderl) >Is it possible to notify getty(8) or login(1) of a list of users >who are granted login at the specified line? Can't say I've thought it through but you might consider writing your own /bin/login which checks access and then execs the vendor supplied login (or exits.) Just move the current login somewhere else for execing and consider the case where people run /bin/login during interactive sessions. And do be careful as a broken login can cramp a system (tho you should be able to fix it in single user mode as login isn't needed then.) It's not ideal, but it might put it all under your control. I really wish AT&T would free up a few programs like login and getty as sources distributed with binary licenses. Some people really do need to add their own logic to these things for various reasons. Maybe someday there'll be a workable GNU version of these programs. But lo, I wander... -Barry Shein, ||Encore||
sjrudek@sactoh0.UUCP (Steve J. Rudek) (10/10/88)
> and /etc/.login a line to check the tty line against the users group,
Under System V.2 (microport, at least), /etc/.login doesn't appear
to be supported. (/etc/profile is, of course, but that is only
good if you force everyone to use sh as their login shell). Other
suggestions? I don't understand why the csh authors/porters didn't
support the idea of /etc/.login since they had the precedent of
/etc/profile.
--
#############################################################
# PRIVATE # Serving The State Capitol #
# PARKING # Of California: sactoh0 #
#############################################################jc@minya.UUCP (John Chambers) (10/11/88)
In article <3818@encore.UUCP>, bzs@xenna (Barry Shein) writes: > From: gfl@tuhold (Gerhard Fleischanderl) > >Is it possible to notify getty(8) or login(1) of a list of users > >who are granted login at the specified line? > > Can't say I've thought it through but you might consider writing your > own /bin/login which checks access and then execs the vendor supplied > login (or exits.) Yeah, I decided the same a few years back, and in fact I did the job. It ain't trivial. But it's a lot of fun learning the bizarre features (?) of the various terminal drivers on the market. > And do be careful as a broken login can cramp a system (tho you should > be able to fix it in single user mode as login isn't needed then.) That's definitely true. I tend to leave the 'console' under control of getty until I'm really sure my program is working correctly on a new system. > It's not ideal, but it might put it all under your control. I think it is ideal. I have the source to my login program, and I can correct its problems and/or change its behavior without begging some uncooperative vendor for help. > I really wish AT&T would free up a few programs like login and getty > as sources distributed with binary licenses. Some people really do > need to add their own logic to these things for various reasons. > > Maybe someday there'll be a workable GNU version of these programs. No need; after determining that my then-employer didn't see any commercial potential to the program, I posted it to usenet under the name 'uutty'. Feel free. Actually, the version I have here is somewhat better documented than the posted version, and I've added some fun new security features. Perhaps I should post a new version. I'm now going through the pangs of trying to make it work right on SunOS; perhaps I'll replace the archived copy with a new one when I'm convinced it is working there. Why doesn't the whole world just adopt the /etc/inittab version of init? Oh, yes, there is the question of the source license...perhaps I'll try my hand at writing that and putting it in the public domain next. On the other hand, maybe I won't find the time. Any takers? I can hardly wait to get my hands on a 4.0 release from ATT/Sun; that should be good for a LOT of #ifdefs in my code. > But lo, I wander... ...and do you wonder as you wander? [Oops; sorry 'bout 'dat ;-] > -Barry Shein, ||Encore|| -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
allbery@ncoast.UUCP (Brandon S. Allbery) (10/17/88)
As quoted from <489@sactoh0.UUCP> by sjrudek@sactoh0.UUCP (Steve J. Rudek): +--------------- | > and /etc/.login a line to check the tty line against the users group, | Under System V.2 (microport, at least), /etc/.login doesn't appear | to be supported. (/etc/profile is, of course, but that is only | good if you force everyone to use sh as their login shell). Other | suggestions? I don't understand why the csh authors/porters didn't | support the idea of /etc/.login since they had the precedent of | /etc/profile. +--------------- It is a nonstandard extension to csh, so every company seems to have its own name for the system-wide csh startup file if they have added it. I have seen, in addition to /etc/.login, the following: /etc/cshprofile (Plexus) /etc/cshrc (Xenix) There may well be others. Try a "strings /bin/csh" (or wherever csh lives on your system). ++Brandon -- Brandon S Allbery uunet!hal.cwru.edu!ncoast!allbery allbery%ncoast@hal.cwru.edu (LAST RESORT ONLY: allbery@uunet.uu.net) DELPHI: ALLBERY comp.sources.misc is moving off ncoast -- please do NOT send submissions direct "So many articles, so little time...." -- The Line-Eater
shocking@physiol.su.oz (Stephen Hocking) (10/17/88)
In article <489@sactoh0.UUCP>, sjrudek@sactoh0.UUCP (Steve J. Rudek) writes: > > and /etc/.login a line to check the tty line against the users group, > Under System V.2 (microport, at least), /etc/.login doesn't appear > to be supported. (/etc/profile is, of course, but that is only > good if you force everyone to use sh as their login shell). Other It does support it actually, but the file is (wait for it) /etc/cshrc under Uport. On HP-UX it's /etc/login.csh, and goodness knows what it is for everything else. BLecchhh foooo. Stephen ----- ....!uunet!munnari!physiol!shocking PS Has anybody seen 2.4 of Uport yet?
allbery@ncoast.UUCP (Brandon S. Allbery) (10/18/88)
As quoted from <105@minya.UUCP> by jc@minya.UUCP (John Chambers): +--------------- | with a new one when I'm convinced it is working there. Why doesn't the | whole world just adopt the /etc/inittab version of init? Oh, yes, there | is the question of the source license...perhaps I'll try my hand at writing | that and putting it in the public domain next. On the other hand, maybe | I won't find the time. Any takers? +--------------- I have no doubt that I could clone System V's /etc/init. The problem is that in various versions of Unix, functionality has drifted around between init and getty; and both impact the structure and/or ordering of /etc/utmp, which can break login and any program which uses getlogin(). (I know, I tried to install a System V getty with the utmp routines changed to write System III-compatible utmp records; and login immediately broke with "No utmp entry".) Thus, to replace /etc/init you must at minimum replace /etc/getty, and you must either know the format *and* *ordering* of /etc/utmp -or- be able to recompile most of the user-level programs on the system. (And if you can do the latter you'd have no trouble doing the former.) BTW, does anyone know how System III decides which records in /etc/utmp are for which /dev/tty* devices? I still want to replace the getty on here, since we are going to need a uugetty-clone here pretty soon... (Suggestions to upgrade our O/S may be sent to /dev/null. It's not an option.) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allbery@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct (But the aliases are NOT on UUNET yet, use the aliases at backbone sites!)
morrell@hpsal2.HP.COM (Michael Morrell) (10/19/88)
/ hpsal2:comp.unix.wizards / shocking@physiol.su.oz (Stephen Hocking) / 2:09 am Oct 17, 1988 / On HP-UX it's /etc/login.csh ---------- It's actually /etc/csh.login on HP-UX.
shocking@physiol.su.oz (Stephen Hocking) (10/24/88)
In article <14670006@hpsal2.HP.COM>, morrell@hpsal2.HP.COM (Michael Morrell) writes: > / hpsal2:comp.unix.wizards / shocking@physiol.su.oz (Stephen Hocking) / 2:09 am Oct 17, 1988 / > On HP-UX it's /etc/login.csh > ---------- > > It's actually /etc/csh.login on HP-UX. Damn, stuffed up again. Well it is one of those things you look at once and then forget..... Stephen