jpc@fctunl.rccn.pt (Jose Pina Coelho) (07/21/90)
Today I had a server crash, it dumped the core and prompted for my
password again. So far so good. But when my .clients finished
another window poped into existance: the xterm of the previous
session, running perfectly with the correct history. I'm shure that
it's the previous window, because it's pid is inferior to the xserver.
This is one *BIG* security hole. The xterm should have died
immediately.
I see one possible method:
When a server comes up it broadcasts a message I'm_up(mach:disp.scr)
When some aplication that is connected screen mach:disp.scr receives
such a packet It should call an handle.
The handle should have a default behavior of { printerror, exit(err) }
However, things like xconsole should have a recovery procedure to try
to reopen the screen as the driver comes up.
I work with a VAX3100, (sg driver) between login and the launching of
xconsole, any write to /dev/console will (90% of the time) scramble
the cursors. (weird, I know)
--
Jose Pedro T. Pina Coelho | BITNET/Internet: jpc@fctunl.rccn.pt
Rua Jau N 1, 2 Dto | UUCP: jpc@unl.uucp
1300 Lisboa, PORTUGAL | ARPA: jpc%hara.fctunl.rccn.pt@mitvma.mit.edu
Home phone: (+351) (1) 640767
- If all men were brothers, would you let one marry your sister ?rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/21/90)
Today I had a server crash, it dumped the core and prompted for my
password again. So far so good. But when my .clients finished
another window poped into existance: the xterm of the previous
session, running perfectly with the correct history. I'm shure that
it's the previous window, because it's pid is inferior to the xserver.
What does "inferior to the xserver" mean? If you mean the pid is a smaller
number, please prove to me that your kernel didn't wrap around pid
allocations, or otherwise somehow generate a lower pid. For example,
give me a way to deterministically reproduce the problem. I can't
imagine how any xterm implementation I know of would survive a server
crash. The only think I can remotely imagine is that an xterm from some
previous session was wedged in the kernel, not yet having completely
established a connection to the server. If you were using xdm and an
MIT server and MIT-MAGIC-COOKIE-1 authorization, the xterm still would
have failed to come up (if you aren't using those, it's your fault you
have security problems :-).jpc%fctunl.rccn.pt@MITVMA.MIT.EDU (07/23/90)
> Today I had a server crash, it dumped the core and prompted for my > password again. So far so good. But when my .clients finished > another window poped into existance: the xterm of the previous > session, running perfectly with the correct history. I'm shure that > it's the previous window, because it's pid is inferior to the xserver. > > What does "inferior to the xserver" mean? If you mean the pid is a smaller > number, please prove to me that your kernel didn't wrap around pid > allocations, or otherwise somehow generate a lower pid. I can't prove, you weren't here. But, Ultrix doesn't reuse pid's, it wraps arround, and it doesn't wrap until at least 16K. All pid's were bellow 500. This machine is generaly used by me (I kill foreign processes with an axe). It takes 9-10 days to get to pid 10000, the system had been rebooted about one hour before. The history in that window was still the same (that was the window from which I launched the app. that crashed the server) > For example, give me a way to deterministically reproduce the problem. The crash was created by: cd /usr/local/lib/bitmaps ; xshowbitmap * > I can't imagine how any xterm implementation I know of would survive a > server crash. Neither can I. I reported the problem to the local systems administrator, and he told me that it sometimes happens. > The only think I can remotely imagine is that an xterm from some previous > session was wedged in the kernel, not yet having completely established a > connection to the server. If you were using xdm and an MIT server and > MIT-MAGIC-COOKIE-1 authorization, the xterm still would have failed to come > up (if you aren't using those, it's your fault you have security problems :-). As I told you, I was already working with that xterm. Yes, we are using xdm, MIT server and MIT-MAGIC-COOKIE-1. HW: VAXstation 3100 Screen: (sg) name of display: :0.0 version number: 11.0 vendor string: MIT X Consortium vendor release number: 4 OS: Ultrix-32 V3.1 (Rev. 9) UWS V2.1 System #1 ---- Jose Pedro T. Pina Coelho | BITNET/Internet: jpc@fctunl.rccn.pt Rua Jau N 1, 2 Dto | UUCP: jpc@unl.uucp 1300 Lisboa, PORTUGAL | ARPA: jpc%hara.fctunl.rccn.pt@mitvma.mit.edu Home phone: (+351) (1) 640767 - If all men were brothers, would you let one marry your sister ?