- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: SYSTEM identifier not [1,4]
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-05-2012 12:16 PM
07-05-2012 12:16 PM
SYSTEM identifier not [1,4]
OpenVMS 8.4 Integrity, patches current to update 6, migrated from Alpha system disk.
We have found the SYSTEM identifier is not [000001,000004] as expected, but [000202,000005].
The SYSTEM account does have UIC [1,4].
My questions are:
What impact does having the SYSTEM identifier not be [000001,000004]?
What should we look out for when we change it?
Further background.
On most systems, we have the account NDM_ADMIN that uses the same UIC as SYSTEM, namely [1,4].
Then we create an identifier, NDM_ADMIN (among other NDM identifiers), and grant it to SYSTEM, and the NDMADMIN account then also acquires the NDM_ADMIN identifier.
On one system, this fails. This is where the SYSTEM rights identifier is not [000001,000004] as expected, but [000202,000005]. There is an account with UIC [202,5], though there are no issues that we know of with that account.
On this system, after granting a rights identifier to SYSTEM, the NDMADMIN account does not acquire the identifier and cannot be used as it is on other systems.
We believe that this is caused by the fact the SYSTEM identifier is not the same as the SYSTEM account UIC, and that NDMADMIN also uses the SYSTEM UIC. We tested this by deleting the NDMADMIN account using UIC [1,4], and copying the SYSTEM account to NDMADMIN using /UIC=[1,5], which was an unused UIC. We are then able to successfully grant the NDM_ADMIN identifier to the NDMADMIN account, and make use of the NDMADMIN account as expected.
Sean
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-05-2012 06:09 PM
07-05-2012 06:09 PM
Re: SYSTEM identifier not [1,4]
A SYSTEM UIC of [202,5] is very odd. It sounds like the [1,4] UIC was modified for some reason.
Assuming that v8.4 on Integrity has the same SYSGEN parameters as v8.3 on Alpha, check you SYSGEN parameter MAXSYSGROUP. That's what defines the maximum group UIC for "system accounts" .
See $ SYSGEN help Sys_params MAXSYSGROUP for details. (I'd post it here but the formatting is likely to be mangled.)
If I was you I'd be changing the UIC for SYSTEM back to [1,4] as soon as possible, by changing the UIC then restarting the system.
(Note the qualifier above - I'm looking at v8.3 on Alpha, not 8.4 on Integrity - so I may be wrong.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-06-2012 07:43 AM
07-06-2012 07:43 AM
Re: SYSTEM identifier not [1,4]
John,
It is the identifier SYSTEM that has the unexpected value.
The UIC for the SYSTEM account is [1,4], as expected. If this were different, I think a lot of bad things would be happening.
I just not sure what kind of things will happen if the identifier is changed at this point.
Sean
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-06-2012 08:51 AM
07-06-2012 08:51 AM
Re: SYSTEM identifier not [1,4]
I agree, if the SYSTEM account UIC was not [1,4], you might have quite a mess! :)
As long as you are not using the SYSTEM identifier in some ACL somewhere, it should be safe to change it. Since the issue seems to be tied to NDM, I would expect any potential fallout to be limited to the NDM (Connect:Direct) application.
You won't break OpenVMS by changing the [SYSTEM] identifier back to [1,4].
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-08-2012 02:51 PM
07-08-2012 02:51 PM
Re: SYSTEM identifier not [1,4]
Sean,
I agree with the other John, you should restore the SYSTEM identifier to its correct value [1,4]. Remember that many places in which identifiers are used, the binary value is stored (for example ACLs). The text name is translated at display time. So, any system defined uses are probably using the binary [1,4] value. These will be OK.
There may be places where the new value has been stored. These may not work as expected (but then they probably wouldn't regardless of the name of the identifier!). I'd suggest also redefining the odd value with an obvious tag, something like:
UAF> ADD/IDENTIFIER THIS_IDENTIFIER_IS_NOT_CORRECT /VALUE=UIC:[202,5]
This should make instances of it more obvious. You can also use the /BY_OWNER qualifier for DIRECTORY to search for files owned by the rogue value, and something like:
$ PIPE DIRECTORY/SECURITY disk:[000000...] | SEARCH SYS$PIPE THIS_IDENTIFIER_IS_NOT_CORRECT
to hunt for ACLs.
I'd also recommend working back through the audit journals to try and work out when the change was made, and by whom. Perhaps you can work out why it happened and what they were trying to achieve.
- Tags:
- ACLs