SecurID® Governance & Lifecycle 7.2 Enablement

Jayvd
Occasional Contributor
Occasional Contributor

RSA IG&L 7.2.0 installer - User creation and internal ID's

A few days ago we installed RSA IG&L 7.2.0 and we noticed that the internal Linux ID's for the users and groups are not enforced anymore however certain application updates do still assume its using this ID's. 

 

In the past the following requirement was in place:

  • Linux User oracle
    • Username: oracle
    • UID: 500
    • Default GID: 500
  • Linux Group oinstall
    • Groupname: oinstall
    • GID: 500
  • Linux Group dba
    • Groupname: dba
    • GID: 501
  • Linux Group datadir
    • Groupname: datadir
    • GID: 502

 

When applying the oracle patches via the rsaimg_updater packages, on extraction the UID's and GID's are archived and predefined which use the internal id's above making the files being owned by nobody. When limited access rights are assigned, this requires super user access to get it rectified. 

 

The following article explains some information about the UID's and GID's. 

 

The current way users are created, the users are considered regular users. The first available UID and GID is assigned which starts at number 1000. This means that in a standard installation the UIDs and GIDs will always be higher than 1000. When the account would be created as a true service account and not a regular user, numbers below 1000 can be assigned and the user's password will not expire. 

 

 

Basically I was wondering if the following could be considered as a future improvement:

  • Could the oracle account be created as a service account
  • When the system has the UID's and GID's not yet assigned to other users, could the installer script claim the UID's and GID's
0 Likes
6 Replies
MHelmy
Moderator Moderator
Moderator

As far as I understand, you can pre-create those accounts before installation with the required UID/GID.

 

As for the installation packages, just change ownership of the files once extracted (chown -R oracle:oinstall <path-to-packages>). That shouldn't be a problem.

0 Likes
Jayvd
Occasional Contributor
Occasional Contributor

Changing these things afterwards is always possible, the reason for starting this discussion is to see what can be delivered standard being compliant with all the various standards out there. 

 

Linux Standard Base - Users & Groups:

  • The system User IDs from 0 to 99 should be statically allocated by the system, and shall not be created by applications.
  • The system User IDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts using useradd.

Current SUSE / Red Hat Standard:

  • The system User IDs from 0 to 999
    • Considered privileged users
      • The system User IDs from 0 to 99 (Reserved by LSB)
      • The system User IDs from 100 to 499 (Reserved by LSB)
      • The system User IDs from 500 to 999 (Reserved for service accounts)
  • The system User IDs > 1000
    • To be used for personal user accounts
0 Likes

Got it. In that case I would recommend submitting this under RSA Ideas for RSA Identity Governance & Lifecycle to be considered for a future release install script (How to make your RSA Idea stand out!).

0 Likes
Jayvd
Occasional Contributor
Occasional Contributor

Created a suggestion to follow the available standards:  

Some of the anachronisms with RSA IG&L user and group GUID are rooted in historical ties to the way Oracle database installer works (or used to work).   We have removed some of these dependencies but there are still many of them.

0 Likes

Excellent and detailed submission.   It should get attention. 

0 Likes