Conference noted::hackers_v1

The following is frequently used for just this kind of situation:

	$ MCR AUTHORIZE
	ADD username /PASS=password /DEVICE=device /DIRECTORY=[directory]
	$ CREATE /DIR device:[directory] /OWNER=[username]
	$ MAIL SYS$INPUT: username /SUBJ="Hello"
	Your account is enabled.
	$ EXIT

re .1:
	I think what he was looking for was a way to allow multiple users
in a single (captive?) account, with each user restricted to a certain subset
of files and/or programs therein.

re .0:
	Am I right?

Re: .2

If that's the case go with the AUTHORIZE idea that Gilbert mentioned except
add an additional switch I think /LOGCMD=User1.COM or User2.COM that contains
the different captive stuff.

If the accounts are indeed captive you should also add /FLAGS=Captive and
Disctly if appropriate.

Steve

	Might also be a good idea to include an ONCONTROLY go to LOGOUT.
Or... a NOCONTROLY as the first line in the COM files?

	-JB

	DISCTLY as a login flag (you do that with authorize) is
usually how that's accomplished.
		<_Jym_>

	Remember that if all the users have the same UIC then
there is NO VMS provided protection between them. Any one of
them can cause havoc to all the others.

	I think he is looking for the ability to have multiple users log
	into the same account and from there be able to access only certain
	files. You could do this by granting indentifiers to each user and
	then add acl's to each file in the directory authorizing the use
	of that file. I don't have a command procedure to do this, but it
	shouldn't be hard.

Ed

But for heaven's sake, why?

	-Neil

re .7:  How do you grant different identifiers to the different users if
they all log in under the same account?

It seems to me that once you, with the help of VMS, are able to differentiate
between different users, then you can do anything you want to either merge
their contexts or separate them.  But to do that, you/VMS must be able to
differentiate them.  That is what UAF records are for!

There might have been reasons for wanting several people to share the same
account before ACLs (although even then you could give them the same UIC,
I guess), but now the reasons are getting fewer and further between, in my
opinion!

Burns

TOPS-20 has another way to treat this problem.  (I'm just mentioning this to
offer another perspective).  Under TOPS-20, Usernames == Directories
(specifically, eash user is associated with a specific directory).  Users
can create subdirectories that can be "logged into."

Disk quota by the way is subtracted from the "owner" directory.

The nice thing about this approach is that unpriveleged users can do this
(good for the teacher - student environment).

Hi: 

	Back again, 

	Re:.6   I know, but they're not VMS types, they're business types.

	Re:.7   Right, could you make a list of users and make it so they can 
		see only what is for them???? You see she distributes Info. to
		the group, but some info is for one and not the other.

	Re:.8	Why, Well, each of the users have VMS accounts of there own,
		but some of the info sent to her is to be shared and worked on
		by many other people. The real problem is that these people
		would rather be logged into her account then know how to get
		to and from the non protected parts of her account.


	ThankX

	Harry

	Re .9  I used a poor chose of words, "same account", what I meant
	to do was this:

	UAF> ADD USER1/PASS=XXX/DEV=DISK$USER:/DIR=[COMMON_USER]/ ...
	UAF> COP USER1 USER2/PASS=XXY
	UAF> COP USER1 USER3/PASS=XXZ

Ed
                                     

Re .12:

Different users, same UIC, same default directory.  One trap is Mail.  If this
setup is used, I suggest for each user, make a separate subdirectory under
[COMMON_USER] and declare it to be the individual's mail directory. 

Dave C.

Maybe I'm a little late for this discussions, but I just did something 
similar for a friend who's coworkers needed to access her account but she
didn't want them to be able to get into her mail.

I added the line $ @PWORD  to her login.com where PWORD.COM was:

$ set nocontrol
$ inquire/nopun pword "Enter Password:"
$ if pword.eqs."FOOBAR" then goto loop
$ write sys$output "User is not allowed Mail access"
$ ma*il :== @M.COM
$ loop:
$ set control
$ exit

and M.COM is

$ write sys$output "Mail Access Denied"
$ exit

Like I said, this is very basic...but it's what was needed.

Sue

Re .14:

Did her co-workers realize that they could defeat this security scheme by
typing $ MAILX instead of $ MAIL?  (Or deleting the MAIL symbol, or
redefining it, or...)  A `security' scheme with holes in it is worse
than none at all, since it provides the illusion of security without
the substance.

	-Neil

Maybe you should try SET COMMAND/DELETE=MAIL.

tom_p

	re : .16

Still not secure. Try :-

$ a = "$sys$system:mail"
$ a

MAIL>

	Dave

	    Maybe if she had CMKRNL privs, she could use one hack to
	change the username to something not in the SYSUAF (MAIL will
	not work under such conditions), then use another hack to get
	rid of CMKRNL privs permanently.
	    Of course, the user could counter-hack with the anonymous
	mail utility hack (above), unless you take away NETMBX privs
	permanently too.
			<_Jym_>