kilroy@mimsy.UUCP (kilroy hasn't been here in *weeks*) (09/21/89)
In article <2449@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > >In article <7383@rpi.edu>, night@pawl (Trip Martin) writes: >>The method I've seen, and used on at least one occasion to plug that >>hole is to make their login shell something that can't be executed, >>usually /dev/null. > > I seen to recall that something complained when I used /dev/null. >Perhaps a log file. I have since then used /bin/true. Changing the password field to something invalid (eg, `*') is more straightforward, but if you really want to keep an account from being used by changing the shell I'd recommend /usr/ucb/yes . . . kilroy@mimsy.umd.edu Darren F. Provine ...uunet!mimsy!kilroy "Money is far more persuasive than logical arguments." --Euripides
barnett@crdgw1.crd.ge.com (Bruce Barnett) (09/21/89)
In article <19711@mimsy.UUCP>, kilroy@mimsy (kilroy hasn't been here in *weeks*) writes: >Changing the password field to something invalid (eg, `*') is more >straightforward Changing the password field isn't enough. They can get in using /etc/hosts.equiv or .rhosts. > but if you really want to keep an account from being >used by changing the shell I'd recommend /usr/ucb/yes . . . Why is 'yes(1)' better than 'true(1)' ? -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
kilroy@mimsy.UUCP (She Blinded Me With Science) (09/22/89)
In article <2458@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > >Changing the password field isn't enough. They can get in using >/etc/hosts.equiv or .rhosts. This is true if you allow net logins, of course. (On the machines at the NIH we aren't even *on* a network, so . . .) On mimsy there is a directory called /etc/restrict/login, in which you can create a file for a user whose account has been restricted and it will let them know what & why. I do not know if this is a BSD standard or a local UMD hack (Mr. Torek produces those rather frequently 8^). >Why is 'yes(1)' better than 'true(1)' ? Because it's more *interesting*. kilroy@mimsy.umd.edu Darren F. Provine ...uunet!mimsy!kilroy "The main problem I have with cats is, they're not dogs." -- Kevin Cowherd
d88-jwa@nada.kth.se (Jon W{tte) (09/23/89)
In article <19747@mimsy.UUCP> kilroy@mimsy.umd.edu.UUCP (Darren F. Provine) writes: >In article <2458@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com > (Bruce Barnett) writes: >>Why is 'yes(1)' better than 'true(1)' ? >Because it's more *interesting*. So, then why not use fortune(6) ? :-) Note the change of 'Woof' in the keywords to 'Moof! (TM)' which really is a TM of Apple Computer Inc. Does it have something to do with the look and feel of computers without protected memory ? ;-) h+ -- A closed mouth gathers no feet.
chris@mimsy.UUCP (Chris Torek) (09/24/89)
In article <19747@mimsy.UUCP> kilroy@mimsy.UUCP (She Blinded Me With Science) writes: >On mimsy there is a directory called /etc/restrict/login, in which you >can create a file for a user whose account has been restricted and it >will let them know what & why. I do not know if this is a BSD standard >or a local UMD hack (Mr. Torek produces those rather frequently 8^). It is a local hack, but actually was Fred Blonder's idea. Since /bin/login applies the restriction, there is no way for anyone to circumvent it except via `su' (or other setuid programs, possibly setuid to that person). The latter is not worth protecting against (too difficult, for too little gain). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
brian@nancy.UUCP (Brian Kilgore WILCO) (09/25/89)
>>Why is 'yes(1)' better than 'true(1)' ? > >Because it's more *interesting*. Or try /bin/login.
steve@nuchat.UUCP (Steve Nuchia) (09/27/89)
In article <193@nancy.UUCP> brian@nancy.UUCP (Brian Kilgore WILCO) writes: >>>Why is 'yes(1)' better than 'true(1)' ? >>Because it's more *interesting*. >Or try /bin/login. There is a very good reason not to use /bin/login, or to use it, depending on what you want behaviour you want. Specifically, whether or not you want modems to hang up after a rejected attempt. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 270249 Houston, Texas 77277 (713) 964 2462 Consultation & Systems, Support for PD Software.
voss@s.cs.uiuc.edu (09/29/89)
I've used /bin/sync on the grounds that: A) There was already a "sync" login without a passwd, so I wouldn't be opening any new holes. B) I never get upset about the disks being sync'ed!
larry@hcr.UUCP (Larry Philps) (10/17/89)
When I was managing hordes of undergraduate accounts at the University of Toronto. I used to change a users shell to restrict his login. There was a directory call "/bin/shells", and if I wanted to turf a user on January 1, I would put an entry in /bin/shells called, for example, "deleteonJan1". It was a simple program that just printed the contents of a text file, dependent on its name, slept for 5 seconds, then exited. Thus a person logging in would see a message saying that the account was to be purged, when it was to go, and who to complain to if that was a mistake. If indeed it was a mistake, a simple chsh fixed things. For that matter, I went crazy and gave students a shell whose name depended on their graduating year. For example, /bin/shells/csh8T9. Then I could have the exactly the same password file on all machines on the net, but control access to the pool of machines by changing the machines on which csh8T9 was a link to csh, as opposed to a link to a "niceTry" error program.
borg@cbnewsc.ATT.COM (daniel.w.meeks) (10/19/89)
>When I was managing hordes of undergraduate accounts at the University of >Toronto. I used to change a users shell to restrict his login. There was a >directory call "/bin/shells", and if I wanted to turf a user on January 1, I >would put an entry in /bin/shells called, for example, "deleteonJan1" ------- This is an interesting way of taking care of accounts. a) input account information b) run create-dirs-and-password-entries-script c) run make-symbolic-link-to-expire-date-script d) run at-job-to-remind-you-of-expire-date e) run at-job-to-resymlink-expired-shells I worked at Purdue's Engineering Computer Network as an SA. Most likely only SA's from Universities would have these kinds of task. Has anyone ever made mention of a SA workshop/conference for University types? I am sure a great deal of good technology could be passed between staff. +-------------------------------------------------------+ | Daniel W. Meeks - dwm@iexist.att.com | |``Computer..Computer.. Ah, a keyboard! How quaint...''| +-------------------------------------------------------+