This content has been marked as final. Show 15 replies
Which other "Linux flavors"? Oracle database only supports Linux based on Red Hat Enterprise, SUSE and Oracle Linux.
I think you are confusing or misunderstanding your available options. Sudo or gksudo run a program as "root". You should never run any Oracle database software as root. You use sudo to execute a command as root. Oracle maintenance tasks are usually performed as the Oracle software owner or OINSTALL group, or whoever has SYSDBA privileges in your setup.
If you have access restrictions and cannot login as user Oracle directly then login using your personal account and simply use SSH with X-Forwarding from command line. You should not set any DISPLAY environment variable with X-Forwarding as it is set accordingly and automatically.
It is generally a better idea to have control of who knows the oracle password than relying on regular system login to gain privileged access. The idea is common for Windows systems or legacy Telnet access, but obsolete for encrypted ssh logins.
[dude@vm210 ~]$ ssh -X oracle@localhost [oracle@vm210 ~]$
The point is we do not want users logging in as any generic account. Even though you are on localhost, you still need to know the "oracle" password in order to ssh to localhost as oracle.
"sudo" and "gksudo" change user to root by default, but can be specified to use a different user (provided it is allowed in sudoers). We already use "sudo", but it does not handle X-Forwarding. That's where you need gksudo.
Generic accounts are are not linked to any specific username. The Oracle account is not a generic account. The sudo command is normally used to provide full or limited root access without having to exchange the root password. Sudo has an option to use another account than root, but why would you want to give the DBA limited access to Oracle tools using the sudo facility? Your security policies seem upside down.
Anyway, as far as I can gather there is no gksudo utility available for any Linux distribution where Oracle database is supported. I suggest to reevaluate your security policies and implementation. Oracle provides other methods to restrict DBA access, for instance, OINSTALL and OSOPER system groups as previously mentioned.
For what its worth, you can set up SSH and X-Forwarding without password prompting by installing SSH user equivalence. In this case you can restrict which user can login without having to exchange any password. X11 xauth is cookie based authentication, which is linked to the login user and breaks using the su or sudo command.
When you suggest "SSH user equivalence", are you simply suggesting using SSH keys?
That does appear to work, but completely bypasses the auditing we were hoping to get from sudo. Our goal was to have all generic accounts (as you mentioned, accounts not linked to a specific user) be audited through sudo.
I think part of the problem is you are focusing on the security of the database, where I am focusing on the security of the Linux system. Whatever security Oracle provides for the database doesn't do me much good at the operating system level.
The other option we are considering is simply locking the "oracle" account. When a DBA needs to work on the system, the Linux admins could temporarily unlock the "oracle" account, and then lock it again when done. This would give us our auditing, even if not as automatic as if we had gksudo, (or an ncurses-based installer for sudo).
You mentioned my security policies seem upside down - I am not sure what you mean by that. It seems pretty common to limit access to generic accounts. Or, are you saying the DBA installs and runs Oracle software from their personal account (and not "oracle")? In such a case, what if you have more than one DBA? I am open to any suggestions you may have. Logging in using a generic account is against our corporate policy, but if we have to make an exception for Oracle products, especially if it's recommended from Oracle, that is what we will do.
I think your security is upside down because it is exchanging the Oracle user for root or implementing application access restrictions common in a Windows user environment. What is the role of the generic accounts? Are they used to prevent external or direct login to the Oracle user account, or what is the idea behind it in terms of system or database security?
I suggest to consult with your DBA about Oracle requirements. GUI tools are not absolutely necessary. X11 forwarding is not absolutely necessary. You can, for instance, also use VNC to run X11 GUI applications and even tunnel VNC access through SSH without the need for any X forwarding. You can also use command line, Enterprise Manager or the dbconsole web interface for many Oracle tasks.
Your plan to use sudo or gksudo to let the Oracle DBA access the Oracle account to run GUI tools sounds very odd and is doomed since it does not allow the DBA to set or unset Oracle environment variables to perform software maintenance tasks, which requires command shell access. In which case you can use ssh password or password-less access instead of using sudoers.
Regarding auditing, what are you trying to audit? Someone using DBCA or sqlplus does not provide you info about system security. From the OS perspective the Oracle account is a non-privileged account, normally.
I think there are assumptions being made that are incorrect. First and foremost, this is an Oracle Linux question, and not a database question. I don't know that I made that clear enough at the start, for which I apologize.
Our previous practice has been to have the DBAs have the password for the oracle account on the Linux filesystem (not database). They would then use this account to run the Oracle Universal Installer, for database, or application server, etc. At the same time, it has been recommended as a security best practice, that generic accounts such as "oracle", "webmaster", or "glassfish" be given no password. Instead, the privileged user logs in with their own user account, and then use "sudo -u webmaster " (as an example), to run a task as that user. We Linux system administrators set it up in the sudoers file that certain groups can sudo to certain accounts (but not root!).
For the most part, this is working fine. The only place we run into issue is running the Oracle Universal Installer, which (from what I am told by our DBA group) needs to be run as the "oracle" user. Right now, they use putty to connect from Windows, with X-ming X Server running; they can sudo to "oracle", but of course the oracle user doesn't have permissions to use their tunneled X server (where the xauth is given to the actual user).
I am wondering if there is a solution similar to gnome's "gksudo", which is like sudo but for xauth. It's a standard package on many Linux distributions, but it looks like RedHat variants don't include it for some reason. This way, the DBA could log in with their own account, run "gksudo -u oracle /u04/DL/Disk1/runInstaller" , they would get a dialog box on their x-server display for their password, and then OUI would run happily as oracle.
Thanks for any suggestions on how I might accomplish this!
I think there are assumptions being made that are incorrect. First and foremost, this is an Oracle Linux question, and not a database question.Sorry but if you compare your last response with my previous response than my suggestion and assessment based on your input is not far from your real situation. ;-)
Being a system administrator can be difficult, in particular if you are in the shooting line between a system audit adviser, company policy and Oracle database team. Please don't get me wrong, but I think such issues or often due to advisory or decision making that applies to MS Windows environments or lack of understanding of DBA system requirements under Unix.
I think your last statement of how your DBA previously worked and had access to the Oracle account and filesystem requires some more understanding. Simply put, the "oracle" user account provides OS authentication to the Oracle database by connecting "/ as sysdba". Such logins will always connect to the database SYS schema. In fact, username and password are not used in such cases and one can even login using "joe/doe as sysdba" and it will work the same way. This type of access is required for many database maintenance tasks. If you need more access control, for instance to split DBA and OS installation teams, Oracle provides the OINSTALL and OSOPER groups, which can be assigned to other OS accounts.
Like previously mentioned, I doubt that using sudo or gksudo will be any good to perform DBA maintenance tasks, in particular when it becomes necessary to modify the shell environment. There are many DBA tasks for which there is no sufficient GUI interface. Although many basic functions can be performed using the oracle web console or Enterprise Manager or GUI tools, the Oracle DBA requires Oracle account login and shell access in particular to perform advanced upgrade, restore and recovery tasks.
By all means of auditing and security needs, a system is only as good as long as it is feasible and supporting what it is used for. I suggest to forget about gksudo or sudo to perform Oracle DBA functions. There is no gksudo for Enterprise Linux, and apparently it is not useful or there is no need for it. I suggest to look into VNC or SSH login with X11 forwarding.
The idea to prevent remote access to known user accounts or even to rename the "admin" account is typical for MS Windows. However, there are better options than using "helper" accounts, and I would certainly not recommend to use any of such account to provide password-less Oracle ssh login. It is better to evaluate and control who really needs DBA or system access and rely on strict password policies.
I'm not using MS Windows or Unix, I am using Oracle Enterprise Linux.
I am not using sudo to do DBA tasks. I am trying to run the Oracle Universal Installer, which my DBA says must be run as "oracle".
I am not connecting to a database, I am trying to install Oracle software (like WebLogic, for example).
I simply want to run the Oracle Universal Installer (runInstaller) without directly logging in to a generic account. Using "sudo -u oracle " would work, except OUI requires a GUI. That is the problem I am looking to solve.
Well, you may think that gksudo will solve your problem based on an error message you received when running the OUI installer, but I cannot help thinking that you may not fully understand Oracle DBA system and access requirements.
I responded to your remarks to comply to security and audit policies in your environment, which has apparently lead to the idea of using gksudo. If all you need is to run the OUI installer, why all the fuss about it? Why don't you just login as the Oracle user? I think you are pursuing a wrong solution with gksudo. If you do not appreciate that, I'm afraid I cannot help you any further.
Nothing to do with DBA tasks. I really don't think you can help me here, Dude (no worries, happens to all of us).
For any Linux admins on this forum, I'll try and explain my situation again.
First and foremost, we want to disallow logins to generic accounts. That is our bottom-line goal. Any solution really needs to keep that goal in mind.
In most cases where we need to do a task as a generic account (oracle, tomcat, glassfish, www, etc), we configure sudo so members of certain groups (ie: webadmins) can "sudo -u" to certain accounts (ie: www). This works very well, with one exception: Oracle Universal Installer.
According to my DBA, we must run OUI as "oracle" (if this is NOT the case, that would be extremely useful to know!). If they try "sudo -u oracle /u04/DL/Disk1/runInstaller", this does not work, since "oracle" doesn't have the xauth to write back to the display. Are there any options that would work? I only mention gksudo at the beginning because I know that works to run GUI programs on non-RedHat systems.
1 person found this helpful
PeteNelson wrote:You have to run the OUI as oracle, however...
According to my DBA, we must run OUI as "oracle" (if this is NOT the case, that would be extremely useful to know!).
If they try "sudo -u oracle /u04/DL/Disk1/runInstaller", this does not work, since "oracle" doesn't have the xauth to write back to the display. Are there any options that would work?First option: teach your DBAs to use the OUI in silent/non-graphical mode.
Second option: copy the xauth across using trusted SSH forwarding: http://joelinoff.com/blog/?p=729
Avi Miller wrote:That would be perfect! I did not know this was an option, but if so, it would be the perfect solution.
First option: teach your DBAs to use the OUI in silent/non-graphical mode.
That would be perfect! I did not know this was an option, but if so, it would be the perfect solution.
You need to check the documentation for each product you actually want to install, but the OUI allows you to create a response file and runs non-interactively. This mode doesn't require a GUI (and is used by EM to do deployments, for example).
For what it's worth you can apparently download and also compile the gksu package from RepoForge, which includes the gksudo utility for RHEL based systems. You can Google the information, however, I would not recommend such a solution.
Using the Oracle Universal Installer in silent mode or non-interactive mode will address the problem of a missing GUI interface, but does not address problems associated with the sudo or gksudo command and the requirement to have physical access to the Oracle user shell and related configuration files. If you configure sudoers to allow other users to have shell access to the Oracle user, which is apparently what you are trying to avoid, you might as well setup ssh user equivalence and use X11 forwarding.
I suggest to discuss your security demands and idea to use the sudo command to run the runInstaller utility in the database forum. Addressing the GUI interface is not the only hurdle that will stand in your way.