Newbie directory protection question - VMS

This is a discussion on Newbie directory protection question - VMS ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Newbie directory protection question

  1. Newbie directory protection question

    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)


    Also, say I have user's login as:

    $disk2:[users.jdoe]

    What protection should $disk2:[000000]users.dir have ?

    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).


    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 ?


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

  2. Re: Newbie directory protection question

    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.

  3. Re: Newbie directory protection question

    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.


  4. Re: Newbie directory protection question

    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".

  5. Re: Newbie directory protection question

    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.

  6. Re: Newbie directory protection question

    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.


+ Reply to Thread