syscrc@GSUSGI1.GSU.EDU (Randy Carpenter) (06/25/91)
I've talked to a couple of SGI folks about this one and they say:
"It can't be done.". Tell me it ain't so...
We have a 4d/280gtx that we use for a graphics class (as well as some
general-purpose UNIX stuff) here at the University. Unfortunately,
we don't have any PI's, and the way our funds look now we probably
won't be getting any for some time :(. So, we need to open the
graphics console up to the class by putting it in a public area
like our student computer lab (so it can be available 24 hours a
day). This will all work ok...until the system goes down for some
reason and thus displays the System Maintenance Menu on the graphics
console, whereby a clever student can proceed to boot the system in
single-user mode and change my root password. Doing a...
setenv console d
...in the PROM Monitor doesn't help because you lose the graphics
monitor altogether.
Can we we make /dev/ttyd1 the full-time console and have a graphics
monitor at the same time?
======================================================================
Randy Carpenter rcarpent@gsu.edu
Georgia State University "mother." (404) 651-2648
Wells Computer Center - W. E. Coyotemcdonald@AEDC-VAX.AF.MIL (06/25/91)
In response to Randy Carpenter: > > >I've talked to a couple of SGI folks about this one and they say: >"It can't be done.". Tell me it ain't so... > >We have a 4d/280gtx that we use for a graphics class (as well as some >general-purpose UNIX stuff) here at the University. Unfortunately, >we don't have any PI's, and the way our funds look now we probably >won't be getting any for some time :(. So, we need to open the >graphics console up to the class by putting it in a public area >like our student computer lab (so it can be available 24 hours a >day). This will all work ok...until the system goes down for some >reason and thus displays the System Maintenance Menu on the graphics >console, whereby a clever student can proceed to boot the system in >single-user mode and change my root password. Doing a... > > setenv console d > >...in the PROM Monitor doesn't help because you lose the graphics >monitor altogether. > >Can we we make /dev/ttyd1 the full-time console and have a graphics >monitor at the same time? > >====================================================================== >Randy Carpenter rcarpent@gsu.edu >Georgia State University "mother." (404) 651-2648 >Wells Computer Center - W. E. Coyote > You could invoke the following program in /.login which will execute when root logs in. It asks for the root password if the runstate of the computer is not multi-user. Look at the comment above XXXX in the source code. -----------------------------------<cut>-------------------------------------- #include <stdio.h> #include <signal.h> #include <pwd.h> #include <stdlib.h> int getPassword(argv) char *argv[]; { #define PASSLENGTH 20 char buffer[PASSLENGTH]; char rootpass[PASSLENGTH]; char altrootpass[PASSLENGTH]; char cmd[100]; char runstate[10]; char *pss,*getpass(); struct passwd *pw; char *info = "Please enter the ROOT password to continue: "; FILE *fp; int done=0,count=0; /* REPLACE XXXX WITH THE ENCRYPTED ALTERNATE MAINTENANCE PASSWORD */ /* JUST CLIP THE CURRENT ROOT PASSWORD FROM /etc/passwd IS OK */ strcpy(altrootpass,"XXXX"); sprintf (cmd,"/bin/who -r | /usr/bin/tr -s \" \" \" \" 2> /dev/null | /usr/bin/cut -d\" \" -f4 2> /dev/null\0"); if ((fp = popen (cmd,"r")) == NULL) { printf ("error: %s executing runstate command\n",argv[0]); return(0); } fgets (runstate,sizeof(runstate),fp); runstate[strlen(runstate)-1] = '\0'; if (strcmp(runstate,"2")==0) { printf ("runstate: multi-user\n"); return(1); } else printf ("runstate: not multi-user\n"); pw = getpwuid(0); strcpy(rootpass, pw->pw_passwd); while (!done) { pss = getpass(info); strcpy(buffer,pss); done = !(strcmp(crypt(buffer, rootpass), rootpass) && strcmp(crypt(buffer,altrootpass), altrootpass)); count++; if (!done && count==3) { printf ("Runstate not multi-user & you don't seem to know the password!\n"); printf ("Last chance to enter the root password or alternate maintenance password!\n"); pss = getpass(info); strcpy(buffer,pss); done = !(strcmp(crypt(buffer, rootpass), rootpass) && strcmp(crypt(buffer,altrootpass), altrootpass)); if (done) return(1); else return(0); } } return(1); } void main(argc,argv) int argc; char *argv[]; { int retval; if (getuid()) { printf ("You must be ROOT to run this program\n"); exit(1); } signal (SIGINT, SIG_IGN); signal (SIGQUIT, SIG_IGN); signal (SIGSEGV, SIG_IGN); signal (SIGHUP, SIG_IGN); signal (SIGABRT, SIG_IGN); signal (SIGTSTP, SIG_IGN); retval = getPassword(argv); if (!retval) { printf ("ZAPP!\n"); system ("/etc/init 0"); } else printf ("AOK...here we go!\n"); } -----------------------------------<cut>-------------------------------------- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv | Kenneth M. McDonald * OAO Corp * Arnold Engineering Development Center | | MS 120 * Arnold AFS, TN 37389-9998 * (615) 454-3413 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ INTERNET: mcdonald@aedc-vax.af.mil LOCAL: c60244@ccfiris
syscrc@GSUSGI1.GSU.EDU (Randy Carpenter) (06/26/91)
> > I would advise you not to put the CPU in a public area; it can easily be > reset and booted in single-user mode by following the instructions in the > documentation. Silicon Graphics is aware of the problem and they have > told me that they are looking into it. I suppose you would have the same > problem even if the CPU weren't in a public area if you had a power failure > or system crash... I have been pushing to have the machine automatically > boot to multi-user, with, for example, a key switch in the "SECURE" > position, and boot to PROM monitor or SINGLE user in "LOCAL" mode. > Perhaps if more of their customers complain, SGI will resolve the problem > more quickly.. > > -Stan Johnson > NASA / Johnson Space Center > Houston, Texas 77058 > (713) 483-4692 > johnson@euler.jsc.nasa.gov Actually, the CPU is in a raised floor computer room one floor beneath the student lab. I understand that the graphics console can be placed up to 150 feet from the CPU, which is within distance of the lab. So, the reset button issue is not a problem. I like your idea of controlling whether the CPU can be booted in single-user mode with a MODE switch setting (SGI should really consider implementing this). However, what I am really trying to do is to get the "System Maintenance Menu" to display on /dev/ttyd1 *and* have the graphics monitor work too. Several people have suggested asking for the password on a single-user boot. This is unacceptable since the "System Maintenance Menu" is still displayed on the graphics monitor and not /dev/ttyd1. Other people have misunderstood my question, thinking that I only wanted to get rid of the console window upon login. Is it really true that you cannot have /dev/ttyd1 be the real console and be able to use the graphics console at the same time? ====================================================================== Randy Carpenter rcarpent@gsu.edu Georgia State University "mother." (404) 651-2648 Wells Computer Center - W. E. Coyote
olson@anchor.esd.sgi.com (Dave Olson) (06/26/91)
In <9106250455.AA07119@gsusgi1.gsu.edu> syscrc@GSUSGI1.GSU.EDU (Randy Carpenter) writes: | I've talked to a couple of SGI folks about this one and they say: | "It can't be done.". Tell me it ain't so... Perhaps the problem wasn't stated as clearly as it is here? | We have a 4d/280gtx that we use for a graphics class (as well as some | general-purpose UNIX stuff) here at the University. Unfortunately, | we don't have any PI's, and the way our funds look now we probably | won't be getting any for some time :(. So, we need to open the | graphics console up to the class by putting it in a public area | like our student computer lab (so it can be available 24 hours a | day). This will all work ok...until the system goes down for some | reason and thus displays the System Maintenance Menu on the graphics | console, whereby a clever student can proceed to boot the system in | single-user mode and change my root password. Doing a... | setenv console d | ...in the PROM Monitor doesn't help because you lose the graphics | monitor altogether. | Can we we make /dev/ttyd1 the full-time console and have a graphics | monitor at the same time? You don't lose the console, it just doesn't start graphics automatically. What you could do is have a script fire up the graphics for you from /etc/inittab or one of the rc scripts. What you lose this way is the ability to have people login as different id's. In IRIX 4.0, the graphics login will come up even when the console is set to 'd' (assuming the graphics is present and working). For now, if the machine is on the net, you could have the person who wants to use the graphics console rlogin, and then type /etc/gl/restartgl which will start the window system as though they had just logged in. An rsh command to do the same thing should also work.
gene@vis.toronto.edu (Eugene Amdur) (06/26/91)
In article <1991Jun26.002448.16305@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: >In <9106250455.AA07119@gsusgi1.gsu.edu> syscrc@GSUSGI1.GSU.EDU (Randy Carpenter) writes: >| I've talked to a couple of SGI folks about this one and they say: >| "It can't be done.". Tell me it ain't so... > yes they told me this as well... >Perhaps the problem wasn't stated as clearly as it is here? > >| [ description of wanting a private console on ttyd1 and a >| public graphics terminal at the same time deleted ] >You don't lose the console, it just doesn't start graphics >automatically. What you could do is have a script fire up the >graphics for you from /etc/inittab or one of the rc scripts. What >you lose this way is the ability to have people login as different >id's. > >In IRIX 4.0, the graphics login will come up even when the console >is set to 'd' (assuming the graphics is present and working). > >For now, if the machine is on the net, you could have the person >who wants to use the graphics console rlogin, and then type > /etc/gl/restartgl >which will start the window system as though they had just logged in. >An rsh command to do the same thing should also work. This is a start but you can go further... I send this to the original poster but perhaps it got lost so... We have a 340VGX and wanted to do the same thing. We got the same answer from SGI but I wasn't happy with no for an answer. I figured out a way to do it. In addition to "setenv console d", you also have to change your /etc/inittab. Just beneath the line that says (or used to say if you've deleted it): #On-board DUART ports We have the following four lines: co:23:respawn:/etc/gl/conslog gr:23:respawn:/etc/gl/grcond < /dev/grcons /etc/gl/pandora -s t0:23:off:/etc/getty ttyd0 co_9600 t1:23:respawn:/etc/getty -s console ttyd1 co_9600 # alt console I can't remember why the first line is needed (it seems that it shouldn't be needed but I seem to remember it not working without it). The second line starts up a pandora on the graphics console to make is usable as a terminal (we like the -s option for various reasons including security). The third line turns off the getty on the ttyd0 port. The fourth line puts up a getty on the tty acting as the real console hidden away in the machine room (I would think that the first line does this too). There are some programs in /etc/gl that are worth noting. /etc/gl/setupcons links the /dev/console device to the actual console (i.e. /dev/grcons if grafics are enabled or /dev/ttyd1 otherwise). And /etc/conslog sets up a getty or pandora on the console (depending on ttyd1 or graphics). Because of the way that SGI detects what to used (i.e. ttyd1 or grcons) there is one problem with this whole setup. If someone logs into the pandora window with the NOGRAPHICS option after his user name then she will log onto the new console (i.e. /dev/ttyd1)! I've reported this as a bug and SGI claims it will be fixed in 4.0. One last thing of note. When you log on to the graphics monitor with the above setup, you don't get a console window (the console is busy after all) in your NeWS setup. So if you don't have /usr/NeWS/bin in your path you have no way of starting up a shell and then the only thing that you can do is log off. As a result we have put /usr/NeWS/bin into our path on the default .cshrc that each user gets, this gives those small rectangular icons in the upper left of the screen which allow you to start shells and the like. Hope this helps. --gene gene@vis.toronto.edu