On Sun, 28 Oct 2007 21:19:01 -0400, JF Mezei
wrote:

>With NFS having screwed with some directroy protection on my system, and
>after Mozilla screwed with some of my files, it started to ussue plenty
>of file protection OPCOM messages about directory files, I need to
>review this.
>
>Is is correct to state that 000000.DIR should be:
>
>000000.DIR;1 [1,1] (RWED,RWED,RE,E)
>

Normal protection on the MFD would be (RWE,RWE,RE,E). Generally
speaking, you should not allow Delete on any directory file, but in
particular NOT on the Master File Directory. While it doesn't really
hurt anything, it would be better to do a

$ set security /prot=(s:rwe,o:rwe,g:re,w:e) 000000.dir

to remove the delete privilege on this file.

>
>Also, say I have user's login as:
>
>$disk2:[users.jdoe]
>
>What protection should $disk2:[000000]users.dir have ?
>

Same as the just suggested: S:RWE, O:RWE, G:RE, W:E

>I don't want to have janedoe be able to do a DIR $DISK2:[USERS] to find
>out which other usernames exist on that system by looking at all the
>user sys$loin directories).
>

Set your USERS directory to only have E access. That way, it will
prevent browsing of all the subdirectories under it.

$ set security /prot=(w:e) $disk2:[000000]users.dir

>
>Is it correct to state that:
>
>$disk2:[users]jdoe.dir should belong to jdoe, that he should have rwe
>acces to it, and the world/group should have no access to it ?
>

It is correct the you, as the owner of your home directory, have RWE
access to it. As to whether or not you want to allow your group or the
world to have any access is up to you. Normal is G:RE and W:E or
perhaps no World access at all. That is really up to you and what you
want/need for a given directory.

>
>If I, as jdoe do a $DIR $disk2:[users.jdoe] what access do I need to
>[000000]users.dir ?

Minimal access to USERS.DIR is Execute: you can see the contents of
this file IF you already know the filename. Sometimes, it makes sense
to have either the Group or World to have RE (Read, Execute) which
allows browsing and file access. Either way is fine; it just depends
on your needs and the purpose of a given directory file.

VMS is Virus Free wrote:
> Normal protection on the MFD would be (RWE,RWE,RE,E).

Interesting. All my MFDs are at RWED RWED RE E, with owner 1,1.

While I know that NFS has screwed with the MFD on one disk, I haven't
mapped any other drives and I have to assume that VMS created those MFDs
at time of disk initialisation (or perhaps BACKUP ?).

>>What protection should $disk2:[000000]users.dir have ?
> Same as the just suggested: S:RWE, O:RWE, G:RE, W:E

OK, that is what it was at before. But Mozilla at one point started to
generate tons of access violations on that directory file so I was
wondering if it needed more access. So I will write this one down as
Mozilla misbehaving.

> Minimal access to USERS.DIR is Execute: you can see the contents of
> this file IF you already know the filename. Sometimes, it makes sense

Thanks. It had been such a long time since I had to dab in directory
security that I wasn't too sure anymore what was needed.

JF Mezei writes:

>VMS is Virus Free wrote:
>> Normal protection on the MFD would be (RWE,RWE,RE,E).

>Interesting. All my MFDs are at RWED RWED RE E, with owner 1,1.

Something added 'delete' permission to the MFD. Owner [1,1] is normal for
a disk initialized /SYSTEM.

>>>What protection should $disk2:[000000]users.dir have ?
>> Same as the just suggested: S:RWE, O:RWE, G:RE, W:E

And this is the MFD protection when the disks are initialized.

>> Minimal access to USERS.DIR is Execute: you can see the contents of
>> this file IF you already know the filename. Sometimes, it makes sense

>Thanks. It had been such a long time since I had to dab in directory
>security that I wasn't too sure anymore what was needed.

For directory files, E allows you to access a file if you know its name,
but not do a DIR or wildcard search. R allows a directory/wildcard access
as well. W allows you to create files in the directory. D allows the
directory itself to be deleted (it must be empty)

Personally I find the fact that VMS goes out of its way to remove O
permission on a directory to be unnecessary (although a MFD should never
have delete permission). It makes an additional step necessary to delete
a directory/directory tree and is unnecessary (VMS disallows deleting any
directory with any contents regarless of protection). It just adds fuel to
Unix weenies' gripe that there you need multiple steps to do the
equivalent of "rm -rf".

In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes:

> Personally I find the fact that VMS goes out of its way to remove O
> permission on a directory to be unnecessary

As I understand it, the reason for this is backward compatibility of
customer programs. Delete permission was withheld on VMS V1, where
such a protection was actually necessary. Since deleting non-empty
directories is no longer possible, the protection is not important,
but theoretically some existing customer program could go bonkers if
it encountered a directory not created with the traditional protection.

> (although a MFD should never have delete permission).

I don't see why not. It will never be empty (since it always contains
itself at the very least), so granting delete permission should not matter.

> It just adds fuel to
> Unix weenies' gripe that there you need multiple steps to do the
> equivalent of "rm -rf".

Just tell them that backward compatibility is a prime goal of VMS.
The most drastic change I was remember was altering the Backup default
to /NOREWIND, because the prior default caused careless users to destroy
data.

In article , JF Mezei
writes:

> VMS is Virus Free wrote:
> > Normal protection on the MFD would be (RWE,RWE,RE,E).
>
> Interesting. All my MFDs are at RWED RWED RE E, with owner 1,1.

Same here, except a) one I have explicitly changed (by mistake; I
changed the protection on all top-level directories on a public disk and
the MFD got caught in the wildcard) and b) the documentation CD, which
has (RE,RE,RE,RE) and I am SURE that I did not change that! :-)

> While I know that NFS has screwed with the MFD on one disk, I haven't
> mapped any other drives and I have to assume that VMS created those MFDs
> at time of disk initialisation (or perhaps BACKUP ?).

I have never used NFS.