jdm@boulder.Colorado.EDU (James D. Meiss) (08/15/90)
When someone is logged onto the console, and a remote
user starts up a gl program, it gets sent to the console.
One of our users has something set so that when he logs
in remotely, his workspace appears on the console.
Is there anyway to prevent these things from happening?
Its rather disconcerting to the console user, not to mention somewhat
of a security problem...
Thanks
Jim Meiss
Program in Applied Mathematics
jdm@boulder.colorado.edukarron@MCIRPS2.MED.NYU.EDU (08/15/90)
jdm@boulder.colorado.edu writes: > When someone is logged onto the console, and a remote >user starts up a gl program, it gets sent to the console. > One of our users has something set so that when he logs >in remotely, his workspace appears on the console. > > Is there anyway to prevent these things from happening? >Its rather disconcerting to the console user, not to mention somewhat >of a security problem... > Yes. I have found two ways. 1) startup workspace from your user.ps or startup.ps files. The incantation was posted some time ago, and I will get it for you if you want it. The good news is that the shell containing workspace will ONLY start if you own the gl window. The problem is that the shell you start from postscript will be run prior to your .login and .cshrc, and will not be a child process that will know anything from your .login. Some people have complained that an editor started from workspace in this way will not know what term to use or which printer to use if you depending on setting these vars in your .login . 2) startup workspace in your .login, and run it only if your TERM is the iris-ansi and your REMOTEHOST is not set. There are many other hacks to test where you are logging in from. The problem with this is that you have to test if workspace is running already, or every new window you open will also run .login and workspace will intrude itself onto your window after you have pushed it below other windows. dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (08/15/90)
On your suggestion to start workspace from .login. A better test is to see if tty is console, if it is the start things up. Usually you only have one console window. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
meuer@s1.msi.umn.edu (meuer) (08/15/90)
karron@MCIRPS2.MED.NYU.EDU writes: >jdm@boulder.colorado.edu writes: >> When someone is logged onto the console, and a remote >>user starts up a gl program, it gets sent to the console. >> One of our users has something set so that when he logs >>in remotely, his workspace appears on the console. >> >> Is there anyway to prevent these things from happening? >>Its rather disconcerting to the console user, not to mention somewhat >>of a security problem... >> >Yes. >I have found two ways. >1) startup workspace from your user.ps or startup.ps files. The incantation >was posted some time ago, and I will get it for you if you want it. The good >news is that the shell containing workspace will ONLY start if you own the gl >window. The problem is that the shell you start from postscript will be run >prior to your .login and .cshrc, and will not be a child process that will >know anything from your .login. Some people have complained that an editor >started from workspace in this way will not know what term to use or which >printer to use if you depending on setting these vars in your .login . >2) startup workspace in your .login, and run it only if your TERM is the >iris-ansi and your REMOTEHOST is not set. There are many other hacks to >test where you are logging in from. The problem with this is that you >have to test if workspace is running already, or every new window you >open will also run .login and workspace will intrude itself onto your >window after you have pushed it below other windows. The way I've gotten around the problem with number two is to put code like this in my .login: if ( "`tty`" == "/dev/console" ) then workspace endif This way only the "true" console window will start the workspace, and you'll only get that window (in my experience) if you are actually at the Iris screen. The only thing that this requires is that you open a console window, which most account configurations do by default anyway. >dan. -mark -- Mark Meuer | 1200 Washington Ave. So. Geometry Supercomputer Project | Minneapolis, MN 55415 meuer@geom.umn.edu | (612) 624-1867
karron@MCIRPS2.MED.NYU.EDU (08/16/90)
A very good idea. I Use a system where I try to keep track of the location and type of every type of port and tty I have logged in from. That way, the system knows where I am, and where my printer closest to me is. I run a sh subshell from .login to run `/bin/tty` through a case statement, unless the REMOTEHOST var is set. However, it truely a hack, and I will have to keep changing it with each new op system. I had not thought that there would be only one console, so only the .login run from console would startup workspace. Anyway, I prefer to startup workspace by hand, at least for myself. Thanks for your note. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+
rpw3@rigden.wpd.sgi.com (Rob Warnock) (08/16/90)
In article <1990Aug15.151151.1237@s1.msi.umn.edu> meuer@s1.msi.umn.edu writes: +--------------- | The way I've gotten around the problem with number two is to put code | like this in my .login: | if ( "`tty`" == "/dev/console" ) then | workspace | endif | This way only the "true" console window will start the workspace... +--------------- (*sigh*) Because of the way the window manager gets your environment variables using "exporttonews", it is very important not to run anything which touches your TTY (even looks at it, such as the "tty" program) in your .cshrc or .login, unless you "protect" it from "exporttonews" with "if(! $?ENVONLY )..." [By the way, this is quite independent of "workspace", per se.] Therefore, you example should read: if ( ! $?ENVONLY && "`tty`" == "/dev/console" ) then workspace endif I think I've posted the excruciating details here before, but will do so again if the above isn't clear... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
smfedor@solar.lerc.nasa.gov (Gregory Fedor) (08/16/90)
In article <67004@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >(*sigh*) Because of the way the window manager gets your environment variables >using "exporttonews", it is very important not to run anything which touches >your TTY (even looks at it, such as the "tty" program) in your .cshrc or >.login, unless you "protect" it from "exporttonews" with "if(! $?ENVONLY )..." >[By the way, this is quite independent of "workspace", per se.] > >Therefore, you example should read: > > if ( ! $?ENVONLY && "`tty`" == "/dev/console" ) then > workspace > endif Potentially stupid question: Does this apply for the /etc/cshrc file as well? -- =============================================================================== Gregory Fedor (216) 433-8468 FTS: 297-8468 Sverdrup Technology smfedor@lerc01.lerc.nasa.gov (128.156.10.14) NASA Lewis Research Center Cleveland, Ohio 44135 ===============================================================================
rpw3@rigden.wpd.sgi.com (Rob Warnock) (08/17/90)
In article <1990Aug16.120834.19609@eagle.lerc.nasa.gov> smfedor@solar.lerc.nasa.gov (Gregory Fedor) writes: +--------------- | In article <67004@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: | >(*sigh*) Because of the way the window manager gets your environment vars... | >... your example should read: | > if ( ! $?ENVONLY && "`tty`" == "/dev/console" ) then | > workspace | > endif | | Potentially stupid question: Does this apply for the /etc/cshrc file as well? +--------------- Yes. (*sigh*) The "exporttonews" program (in the case of "csh", "sh" is similar) actually does, in a manual equivalent of "popen()": fork(); ...other stuff... execl("/bin/csh", "-sh", "-c", "source .login;echo ::: ENV;exec /bin/env", 0); Note that arg#0 ("-sh") begins with a "-" indicating a "login shell" (see the csh(1) man page). So, yes, both /etc/cshrc and ~/.cshrc get run. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
msc@ramoth.esd.sgi.com (Mark Callow) (08/21/90)
In article <67004@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes: [ yet another variation on starting WorkSpace from a .login ] |> |> if ( ! $?ENVONLY && "`tty`" == "/dev/console" ) then |> workspace |> endif |> You can start the WorkSpace automatically when you log in on the console without anything in your .login or your user.ps. Simply bring up the System Manager from the systemchest, double click over the "users" icon, wait for the User's Tool to appear, double click over the icon representing your login, wait for the user display and click the "WorkSpace: On" button. If you don't like graphical interfaces, you can achieve the same effect with this command: % echo on > ~/.workspace/autostart The WorkSpace will now start automatically every time you login on the graphics console. N.B. If you have a personalized user.ps file in which you rewrite the basicRestartActions array you must ensure that the proc "autoWorkSpace" is still being called. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
betsy@vesuvius.esd.sgi.com (Betsy Zeller) (08/22/90)
In article <24759@boulder.Colorado.EDU> jdm@boulder.Colorado.EDU (James D. Meiss) writes: > > When someone is logged onto the console, and a remote >user starts up a gl program, it gets sent to the console. > One of our users has something set so that when he logs >in remotely, his workspace appears on the console. > Your user has probably put a command to invoke workspace into his .login or .cshrc file. If he wants workspace to start up automagically, he should invoke the system manager from the System chest, open the user tool, and open his own user icon, and choose the 'on' setting for automatic workspace start up. This will behave itself in a reasonable fashion, and only start up if he is logging on to the console. Betsy Zeller betsy@sgi.com