Is it a good idea to use setfacl for additional group permissions?
 

Hello,

Long story short, I spun up a VM loaded with RHEL and had to install Oracle DBMS on it (for work).

After some nifty tutorials, I wound up with the "application" directory for Oracle and it's component right under / in a folder called u01.

The problem later became that my PM did not want me giving away the oracle account to some outside folk who do not deal with our work on a day-to-day basis. This made sense as the oracle user was used to install the DBMS and is the owner for the entire directory and its subcontents.

For whatever reason, in my head at the time, I came up with the suggestion to just come up with a new group (I blame Microsoft). After some Googling, I discovered I could then give this group explicit access to particular files/folders where this outside/additional person was requesting access for—items which existed inside this oracle directory (u01).

TL;DR:
Fast forward to today, I have been successful in enabling access to the resources this person has been asking for (e.g. log files) by adding them to the new group and then using setfacl to update the ACLs to include necessary permissions for this group on the requested resource. This new group is not the associated group in any of the objects found under the application folder where as otherwise listed from a command like ls -l.

My question is now: is this a bad thing to do? For those who have more experience than I or who have a better understanding of Unix/Linux permissions, have you ever encountered unexpected consequences from doing something like this?

My concern is that I'm probably not following some best practice for access control when it comes to file permissions and the like.

Heh. Haven't dealt with OFA for a while.

IMHO, that's what ACLs excel at: providing fine-grained access to files and directories over the standard user:group permissions. (Back in my VMS days, I configured project directories to have no standard permissions at all except through the ACL mechanism so that users not associated with a project and didn't have the necessary rights identifiers couldn't go wandering around its files.)

The last time I worked on a system with Oracle, we had two groups "dba" for the DBAs (duh) and "orauser" for the people who merely "used" the database instance(s). Not sure if we needed to grant access to someone not a member to either of those groups to have access to "u01" (or, in our case, "/u0[1-4]") but the following may be a situation similar to your's. I occasionally got calls from a DBA who couldn't access a file. The DBAs (joe:users, bob:users, etc.) would work on scripts and wind up owning the modified script preventing another DBA from modifying it without me changing the permissions for them. They'd start fooling around with their mask, chmod, chown, and have permissions all boogered up. An ACL giving anyone in the "dba" group read/write access to the scripts (and the directory they lived in) was the simplest solution. It wasn't a permissions problem with the "/u01" tree but I suspect it's similar to what you are/were encountering.

The "consequences" weren't unexpected and involved getting the DBAs trained to realize that normal permissions they'd see via "ls -l" may not be giving them the whole picture.

HTH...