Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Rightslist.dat

FOX MULDER_2
Frequent Advisor

Rightslist.dat

A query on rightslist.dat.......

Just need to know what impact will there be if the protection is changed from (RWED,RWED,R,R) to (RWED,RWED,,).

Thanks
10 REPLIES
Robert Gezelter
Honored Contributor

Re: Rightslist.dat

Fox,

A quick check of some of my systems seems to indicate that removing World access (the last "R") is not a problem. The other standalone "R" (in the third position) is for Group access. Since RIGHTSLIST.DAT is probably owned by SYSTEM, Group access is roughly equivalent to System access (the first RWED).

Personally, since the default appears to be [RWED, RWED, R, ], I would probably recommend setting it to that.

For an overview of the actual file protection check, see the OpenVMS Guide to System Security (available from the OpenVMS www site at http://www.hp.com/go/openvms ) or the reproduced diagram in my chapter in the Handbook of Information Security (H. Bidgoli, Ed, Wiley, 2005).

- Bob Gezelter, http://www.rlgsc.com
FOX MULDER_2
Frequent Advisor

Re: Rightslist.dat

Thanks Robert,
but what if an user with an identifier logs in,will he be able to get all access he holds ?

Thanks
Robert Gezelter
Honored Contributor

Re: Rightslist.dat

Fox,

A good and reasonable question. The best answer would be to review the code or the Internals and Data Structures manual, but I will try to give a simplified explanation.

The components that access RIGHTSLIST operate with System protection as part of the login process (and some other situations). They do not operate as part of the user's protection context.

- Bob Gezelter, http://www.rlgsc.com
Jan van den Ende
Honored Contributor

Re: Rightslist.dat

Fox,

>>>
but what if an user with an identifier logs in,will he be able to get all access he holds ?
<<<

For you info, our RIGHTSLIST has the default protection (as shown by Bob), and we DO make extensive use of identifiers.
NO user can access ANY application without holding the relevant ident.

Yes, the default access is entirely adequat.
And giving World READ access just might compromise your security...

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: Rightslist.dat

Given the usual owner, granting access to the group is inconsequential; the usual owner is a SYSTEM UIC, and SYSTEM UICs can access via both the SYSTEM portion of the MASK and the GROUP portion of the mask. So the change is moot from a security standpoint.

Changing off the official mask is problematic in terms of support. It might work, it might not. It might throw an extra audit or such. Or something might eventually go off the rails.

The HP-specified protection mask for this file is RWED,RWED,R,R, and the file is owned by SYSTEM. Which means that the G:R might cut down on the need to use the SYSTEM mask to access the file, though it certainly doesn't alter the ability of a SYSTEM accessor to access the file. This per the Security Manual, and its list of files and protections. (And what's in the manual was the NCSC Class C2 security settings.)

I'd recommend against changing this protection without a massively good reason, and no security auditor I've encountered has managed to convincingly make that case.

As to what might go wrong, go try it. Probably nothing. But as to the future, who knows.
David Jones_21
Trusted Contributor

Re: Rightslist.dat

I believe some applications that want to translate identifiers between names and values will fail.

It seem to recall that the default file protection for rightslist.dat was initially world readable but later changed to no world access for security reasons. If rightlist.dat is readable, it can reveal a list of valid usernames on the system.
I'm looking for marbles all day long.
Willem Grooters
Honored Contributor

Re: Rightslist.dat

I don't think there will be a problem, but you may have to take precautions.
At login, the login process checking the user's credentials and setting the environment is not trunning as an ordinary user - it's a SYSTEM matter. So Read access isn't needed.
If a user requires extra identifiers, bet keep it under program control, but the image should be installed with sufficient privilege to access the file (READALL might do?).
Willem Grooters
OpenVMS Developer & System Manager
John Gillings
Honored Contributor

Re: Rightslist.dat

FOX,

As others have noted, it's probably best to keep the default protection. Though I'm not sure we've clearly established what that is! I believe it SHOULD be (RWED,RWED,,) for reasons that will become apparent.

For RIGHTSLIST the SOGW protection is not very relevant because the file isn't normally accessed directly through RMS. All accesses to RIGHTSLIST should be through system services $IDTOASC or $ASCTOID, so even unprivileged users access the file via the SYSTEM mask (albeit in a controlled manner).

Even if there is no read access to the FILE an unprivileged user can translate rights identifiers in either direction using the system services (or lexical function jacket F$IDENTIFIER). They can also perform a wildcard search with $IDTOASX.

The one exception - identifiers with the NAME_HIDDEN attribute can only be translated by holders of the identifier, or with READ access to RIGHTSLIST. Thus, the only real consequence of granting world READ access to RIGHTSLIST is to negate the NAME_HIDDEN attribute. (Although it's not documented as such, I'd expect this also affects HOLDER_HIDDEN. Personally I can't see much use for NAME_HIDDEN, but I can see that HOLDER_HIDDEN might be useful - asking "what is the arbitrary name of this object" doesn't really help security, but preventing the question "who can use this access right" most definitely does).
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Rightslist.dat

>(Although it's not documented as such,
>I'd expect this also affects
>HOLDER_HIDDEN.

I was looking in the wrong place. This IS documented under $FIND_HOLDER:

"Read access to the rights database is required to obtain information about identifiers marked HOLDER_HIDDEN"

Also, $FIND_HELD says:

"Read access to the rights database is required to obtain information about identifiers held by other users."

My conclusion is that RIGHTSLIST should NOT have WORLD:R access. GROUP doesn't really matter as it's the SYSTEM group anyway.
A crucible of informative mistakes
DECxchange
Regular Advisor

Re: Rightslist.dat

> but what if an user with an identifier
> logs in,will he be able to get all access > he holds ?

Hello,
If you add an IDENTIFIER to a user account using the AUTHORIZE utility, and then if you do a SET FILE/OWN=, that user will own the file and have full access to it. This way, you can then restrict access to other GROUP and WORLD users by doing a SET PROT=(G:,W:) or SET PROT=(RWED,RWED,,). You might already know this, but the set prot command goes by (S,O,G,W). If you do a dir/own/prot on files, you will see who owns them and what file protections each file has. System users can override the file's ownership and still access the file.