| Title: | DEC TCP/IP Services for OpenVMS |
| Notice: | Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System |
| Moderator: | ucxaxp.ucx.lkg.dec.com::TIBBERT |
| Created: | Thu Nov 17 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5568 |
| Total number of notes: | 21492 |
We are trying to protect files on VMS from accidental writes and deletes
from UNIX.
We created a dynamic rights identifier on VMS. Everyone in our group has
the rights identifier on their account. The group's set up procedure
disables this rights identifier. We protect our important files with the
following ACL:
mumble.dir [DECC,CBLDR] (RWED,RWED,RE,RE)
(IDENTIFIER=DECC_OWNER,
ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=DECC_OWNER,
OPTIONS=DEFAULT,
ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
mumble.C;1 [DECC,CBLDR] (RWED,RWED,RE,RE)
(IDENTIFIER=DECC_OWNER,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
Everyone can read the files. DECC_OWNER can write to the files, as can
[DECC,CBLDR]. Since DECC_OWNER is normally disabled, people can't
accidently trash the files. Since everyone can enable DECC_OWNER if they
need to, they can update the files on the rare occasions that that is
necessary.
These files are visible on our UNIX machines. We do not want people to be
able to accidently write to the files from UNIX. They appear to be
protected:
ls -ld /usr/proj/gem_c/cbldr/temp/sub
drwxr-xr-x 2 cbldr decc /usr/proj/gem_c/cbldr/temp/sub
but we find that we can still create new files in the directory so
protected.
cosf> ls -l /usr/proj/gem_c/cbldr/temp/sub
-rwxr-xr-x 1 cbldr decc 1 Jan 29 16:08 abc.c
cosf> touch /usr/proj/gem_c/cbldr/temp/sub/xyz
cosf> ls -l /usr/proj/gem_c/cbldr/temp/sub
-rwxr-xr-x 1 cbldr decc 1 Jan 29 16:08 abc.c
-rw-rw-r-- 1 reinig decc 0 Jan 29 16:11 xyz
We can also remove files from UNIX, albeit UNIX does prompt us, asking if
we really want to do that.
cosf> rm /usr/proj/gem_c/cbldr/temp/sub/abc.c
rm: override protection 755 for /usr/proj/gem_c/cbldr/temp/sub/abc.c? y
So we do have protection against accidental deletion.
We cannot write to the files from UNIX.
The only way we've found to prevent accidental file creation is to remove
the DECC_OWNER rights identifier from the account. Is there some way to
tell UCX not to use the DECC_OWNER rights identifier? Is there some ACL we
can put on the files to prevent UCX from creating files in the directory?
August G. Reinig
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5172.1 | UCXAXP::GEMIGNANI | Thu Jan 30 1997 18:23 | 10 | ||
I am assuming that you are using NFS to access these files, right?
If so and, as you indicated, the members of the group have the
DECC_OWNER identifier enabled by default, then their proxy (I am also
assuming that you setup a proxy for them that matches their identity on
VMS) has this identifier present (and enabled), thereby allowing them
to write as you are reporting.
Am I correct in my analysis, or did I miss something?
| |||||
| 5172.2 | CXXC::REINIG | This too shall change | Fri Jan 31 1997 09:33 | 8 | |
I think you are correct in your analysis. I would have to check with
the system manager to be certain but what you said matches what I
believe to be true.
Is there any way to do what I want to do easily. What we have right
now is acceptable but we would like to prevent the writing.
| |||||
| 5172.3 | UCXAXP::GEMIGNANI | Tue Feb 04 1997 22:02 | 15 | ||
To preclude the NFS users from having this identifier by default, I
would create a duplicate identity that is used specifically for the
network. So, I could be GEMIGNANI but perhaps GEMIGNANI_ on the
network (via UCX proxy). That username would match GEMIGNANI almost
exactly with the exception that it doesn't have the powerful identifier
granted to it by default.
Note that you need not have matching names ... you could chose anything
you want (for example, you could pick the UIC and create a name like
NFS_xxxxyyyy where the xxxx and yyyy are the octal UIC. This way, you
could find all records for the user by doing a SHOW [xxxx,yyyy]/brief
in AUTHORIZE.
That's just off the cuff; there could perhaps be alternatives.
| |||||
| 5172.4 | Nice idea that didn't work | CXXC::REINIG | This too shall change | Thu Feb 13 1997 09:33 | 7 |
The suggestion doesn't work. My system manager informs me that if I
have two account, when he removes a rights identifier from one account,
it disappears from the other. So, while I can have two accounts with
different process quotas, I cannot have two accounts with different
rights identifiers.
August
| |||||
| 5172.5 | There are other ways ... | LASSIE::GEMIGNANI | Tue Feb 18 1997 17:17 | 19 | |
Yes, if the two users have the same UIC then this could happen.
There are two alternatives that I see:
1) If you set UCX$NFS00000000_SECURITY, then each user will have
the identifier UCX$NFS_REMOTE tagged onto their identity.
Your ACLs could include a way to inhibit access with this
identity.
2) You could use a two-stage approach, where you grant a harmless
identifier which, when sensed by a program running in
SYLOGIN.COM, would grant you the potentially harmful one.
The program would need special privileges (perhaps CMKRNL, etc)
to do this, but it can also sense the mode (interactive, batch,
etc) then use SYS$GRANT_ID to give you the super-identifier.
This is not one of those cases where we can be as flexible as people
would like.
| |||||
| 5172.6 | DECCXL::REINIG | This too shall change | Wed Feb 19 1997 12:39 | 4 | |
I think we come to the stage where the benefit isn't worth the cost.
Thanks for all the suggestions.
August
| |||||