NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/os/vms/22148

Internet Message Format | 1993-01-28 | 5.5 KB

Path: sparky!uunet!opl.com!hri.com!spool.mu.edu!agate!dog.ee.lbl.gov!ucbvax!IPG.PH.KCL.AC.UK!SYSMGR
From: [e-mail]
Newsgroups: comp.os.vms
Subject: ?1-800 from outside USA? + obs. ACLs, resources.
Message-ID: <242001A9_00186610.009673D25A01EB40$[e-mail]>
Date: 27 Jan 93 12:49:40 GMT
Sender: [e-mail]
Organization: The Internet
Lines: 103

A 3-part posting. First a question that's nothing to do with VAXes. I'm
sure I once saw mentioned a phone number in the USA that I could dial with
a touchtone phone, which would then dial a USA 1-800 number for me. This
would be incredibly useful to me (and probably a lot of other non-US folks).
(I'm not expecting the call to be free!) At present, many USA companies
publish only 1-800 numbers with no indication of location, and
in the UK our hapless telecom provider BT is quite incapable of translating
these numbers into anything callable.

Second, a small document about ACLs and resource identifiers that I think
might be of some use to people. And finally, a protest about the flamers.

-------------------------------------------------------------------
obs. ACLs, resources, how to make them work for sharing disk quota.

For a long time, I've been trying to make files owned by a resource behave in
what I regarded as a sensible way. The rules I wanted were:

1. Any user granted the resource (say FOO) could create files owned by FOO
   in a directory disc:[FOO]
2. Anyone with the FOO resource could fairly easily delete any such file,
   but preferably not with a simple DELETE command on its own
3. The user who put the file there could delete the file with a simple
   DELETE command
4. It would be hard for anyone with the FOO resource to get the files into
   such a state that only privilege could delete them
5  The default protection for everyone not holding FOO would be RE (or
   anything else appropriate)

Note that the objective here is disk quota owned collectively by a group
whose members change from time to time. It's not enhanced file protection.

The answer I have found is to set up, as system manager, the directory and
ACLs as follows:

$ CREATE/DIR/OWNER=[FOO] disc:[FOO]
$ SET DIRECTORY/ACL=( -
   (DEFAULT, S:RE, O:RWED, G:RE, W:RWED), -          ! NB W:RWED
   (ID=FOO, ACC=R+W+E+C), -
   (ID=FOO, ACC=R+W+E+C, OPT=DEFAULT), -
   (ID=*, ACC=R+E), -
   (ID=*, ACC=R+E, OPT = DEFAULT) -
  )

The key to it is the default protection being as insecure as possible! In
effect, you're relying solely on ACLs and making SOGW protection irrelevant.
I found this extremely counter-intuitive.

The next pair of ACLs for ID=FOO allow anyone with FOO to control the file.
Delete access is missing, so to do that you have to use the C access to change
the ACL. VMS gives the user who created the file in the first place a "free"
ACL which specifies RWEDC access, so that person can use DELETE on its own.

The final pair of ACLs specify the access for anyone not granted FOO - RE
in the above example, ACCESS=NONE if you're after security rather than sharing.
You can put ACLs for other identifiers or users between the ID=FOO ACL and the
ID=* ACL, the order is important because for any user, the first ACL in the
list which matches his IDs is used, regardless of whether there is a more
permissive one further down the list.

W:RWED for the SOGW protection is so that if the authorised people louse up
the ACL the result isn't a file that only the system manager can delete.
As long as the ID=* ACL is present, it not significant because nothing can
fall off the end of the ACL list and use the SOGW protection. It becomes
omportant when a FOO user managers to louse up the ACL and uses SET ACL/DELETE
on it. If you're trying to be ultra secure, this is of course not safe.
-----------------------------------------------------------------------

** FLAME ON **
obs. flamers. HAVE YOU THOUGHT ABOUT THE POSSIBLE SIDE EFFECTS OF YOUR NOISE?

From where I am,
(a) our info-VAX distribution is about a week behind. This is almost certainly
    because the flame messages have caused the UK info-VAX server to run out
    of bandwidth. (Don't tell me to upgrade it, I'm just a client).
(b) it's not inconcievable that you've contributed to at least one system crash,
    the one that hit me last night. The active process was the info-VAX
    redistributor. Of course that may be irrelevant, and I'll never know,
    but  if we hadn't had all that content-free rude-words garbage to digest
    then just maybe it wouldn't have happened.
(c) it's also not inconcievable that you'll deny someone with an incipient
    heart attack his last few days on earth. Do you REALLY want to do that?

I can cope with naive users who won't RTFM and/or post relevant details very
easily by hitting delete; this has little effect on my blood pressure.
Occasionally I'll even help. On the other hand, insulting messages rammed down
my e-mailbox make me angry, and meta**N flames make me angry**N (angry>1).

**FLAME OFF**

I fear the word "flame" is going the same way as "hacker". Flame used to
mean a posting with much valuable technical content, but expressed in a rather
passionate manner from a biassed viewpoint. This was often acknowledged by
the author who bracketed it with **FLAME ON ** and **FLAME OFF**. Today it
just seems to mean a stream of content-free gibberish full of four-letter words.

Please, if you want to be rude to someone don't inflict it on the rest of us.

    Yours,
        Nigel Arnot

        [e-mail]   (internet)
        [e-mail]        (bitnet)