| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
What about protection on WSA devices created by a user with SET
DISPLAY? I've notice that it allows anyone to modify or delete
these devices (W:RWLP). Shouldn't the owner be the only user
allowed to modify/delete these devices?
With the current protections, a user may perform a
SET DISPLAY/NODE=OTHERNODE/TRANS=DECNET and forget to place the
/CREATE qualifier on the command and thereby change the WSA
device used by LOGINOUT after the session has ended. Now
LOGINOUT tries to bring up the Login Dialog Box on OTHERNODE
rather than your local node.
Another situation. A user has several DECterms and on some he
has performed a SET DISPLAY/CREATE. He now wants to be a good
citizen and clean up after himself with SET DISPLAY/NOPERM. He
inadvertantly performs the SET DISPLAY/NOPERM on a DECterm which
is pointing to the default WSA device. Now the only WSA device
that is left on the system is WSA0:. This causes problems also.
Last situation. I know that we would never see this problem but
a user modifies another user's WSA device to get any newly created
connection to display on his workstation to see what he is doing.
This could be a big security hole don't you think?
Making it so the owner is the only one that could modify/delete
a WSA device could solve a lot of problems and stop this particular
security hole.
Any options?
David
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 342.1 | Oops, a couple of mistakes | OIWS20::BRYSON | Wed Mar 08 1989 01:03 | 14 | |
Not really true about the Login Dialog Box trying to come up on another
node. The session manager will ACCVIO. Just hope that you leave a
DECterm up before you end the session or you will have not way to
restart the server unless you login remotely.
> Any options?
Should be Any Opinions?
Sorry about that.
David
| |||||
| 342.2 | Any takers? | OIWS20::BRYSON | Sun Mar 12 1989 21:02 | 10 | |
Does no one see this as a security hole?
It is also the only reason that I could see for SET DISPLAY to create a
new WSA device instead of looking for a WSA device that has your
specifications. You would not want to link to another persons WSA
device and have him change it from underneath you.
David
| |||||
| 342.3 | MU::PORTER | what's in a name? | Sun Mar 12 1989 21:16 | 21 | |
OK, I'll bite.
Technically, I'll agree it is a "security hole" in that you
could interfere with someone else's application. Have you tried
changing the protection on the template device to see if it gets
propagated correctly?
It doesn't do you any good having me agree with you, though...
I'd submit a QAR if I were you!
I don't agree with the paragraph that says "...only reason for SET DISPLAY
to create a new WSA device..." -- the reason I want /CREATE to create
a new device is to avoid crosstalk between my own applications.
For example, appl #1 has created a WS unit and is about to delete it.
Appl #2 executes SET DISPLAY which decides it doesn't need to
create a unit because there's one already. Appl #1 deletes the
display it owns. Now appl #2 finally gets to XOpenDisplay, which fails
because the WS has gone away. OK, it could be fixed with a ref
count somehow, but I'm not sure it's worth the effort.
| |||||
| 342.4 | Oops! Let me rephrase... | OIWS20::BRYSON | Mon Mar 13 1989 03:32 | 13 | |
Let me rephrase.
"Only reason" should have been "a very good reason". What I was
referring to was similar to the fact that you stated: someone or some other
process could do something with the WSA device that could interfere
with your application. Sorry about the wording.
I'll try setting the template protections and I'll QAR it. Just
wanted to see if I was missing something fundamental.
David
| |||||