From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 26-MAY-1989 11:57
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: How do you tell if it's a directory?

Message-Id:  <8905261546.AA03418@crdgw1.ge.com>
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu, 25 MAY 89 22:07:26 PDT
Received: from Venus.YCC.Yale.Edu by KL.SRI.COM with TCP; Thu, 25 May 89 17:05:41 PDT
Date: Thu, 25 May 89 20:10 EDT
From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)"
 <LEICHTER@Venus.YCC.Yale.Edu>
Subject: Re: How do you tell if it's a directory?
To: munnari!murtoa.cs.mu.oz.au!mimir!hugin!augean!fang!tcs3!ksh@uunet.uu.NET,
        INFO-VAX@KL.SRI.COM
X-Vms-To: 
 IN%"munnari!murtoa.cs.mu.oz.au!mimir!hugin!augean!fang!tcs3!ksh@uunet.uu.net",INFOVAX

[Mr. Hayman is discussing the SET FILE/NODIRECTORY command in VMS V5.1]

	I have tried this on an 8300 running VMS 5.1, and from an unprivileged
	account I have found NO WAY that I can turn OFF the directory bit on a
	file, even when I own the directory and have O:RWED access. This
	includes the SET FILE/NODIR command and a program to do the correct
	$QIOW call (same program used to work nicely under V4.7 and earlier).
	Looks like you now need something of the order of SYSPRV to stand on a
	directory file like this.

Yes; this change in Version 5.0 of VMS, along with a general tightening up of
file security.

	It is however interesting to note that you can take an ordinary file
	and turn ON the directory bit (using the $QIOW call) without any
	problems at all (apart from then getting rid of the resulting,
	presumably invalid, "directory" :-)

	Seems to me like this is the wrong way round - you should be able to
	turn the bit OFF easily, but turning it on should be harder

No, not really.  There are two reasons I can think of why VMS was changed to
NOT allow you to turn the "is a directory" bit OFF:

	1.  An unprivileged user who does that creates garbage (lost files)
		that he cannot clean up.  The only way to clean it up is
		for the system manager to do an ANALYZE/DISK/REPAIR.

		This isn't an overwhelming argument since an unprivileged
		user can create lost files anyway (with SET FILE/REMOVE, or by
		just creating a file with no directory entry to begin with).

	2.  (This is what I think lead to the decision):  VMS V5 closed up
		holes by which a user could do things that had the effect
		of actions for which he had no privilege.  For example, you
		can no longer rename a file unless you have delete access to
		it - since renaming it to some bizarre name is equivalent to
		deleting it as far as anyone being able to make use of the
		data is concerned.

		If an unprivileged user can SET FILE/NODIRECTORY a directory,
		then delete the directory, he has made inaccessible - often in
		practical effect, deleted - all the files in the directory -
		even if he didn't have DELETE (or, for that matter, ANY)
		access to them.

Now, even (2) is not a complete justification for the change, since a user
could still, with DELETE access to the directory, simply rename it to some-
thing bizarre, with almost the same effect.  The scheme isn't perfect.  But
it makes you work harder, and it certainly eliminates a great way for you
to shoot yourself in the foot!

There's another consideration:  Just why would you WANT to turn off the "is
a directory" bit?  There is only one reason I know of:  To delete a directory
that has somehow gotten damaged, so that it's impossible to get rid of all the
files in it.  However, any such damage indicates a problem SOMEWHERE, whether
in software or hardware.  It should be brought to the system manager's atten-
tion.

As to why turning ON the directory bit doesn't require privilege:  You can't
actually do much harm to the system by making random files into directories.
You CAN evade another of the VMS V5 security "tightenings":  As of V5, you
can no longer use SET FILE/ENTER (or the underlying QIO) to create a direc-
tory entry pointing to a file you don't have access to.  A very minor point:
Protections are at the file level, not the directory level - there was no
real hole in the security here, but you could leave a trap for an unwary
system manager.  My guess is that this change will eventually appear, and that
the main reason it wasn't done in V5 is that it would have required additional
work to allow CREATE/DIRECTORY and LIB$CREATE_DIR to continue to work for
unprivileged users.
							-- Jerry