1

I have Oracle 10g installed on RedHat Enterprise Linux 5.

I have 2 users that use Oracle:

uid=501(user1) gid=502(group1) groupes=500(oinstall),501(dba),502(group1)

and 

uid=500(oracle) gid=500(oinstall) groupes=500(oinstall),501(dba),502(group1)

When a user tries to stop a listener that was started by the other user, I get this error:

TNS-01190: The user is not authorized to execute the requested listener command

How can I allow both users to stop the listener, regardless of who started it?

Improve this question
0

3 Answers 3

Reset to default
4

The description for the message you're seeing is:

Cause: Most of the listener administrative commands are only intended to be issued by privileged users, for example DBAs or system administrators. If the listener password is not set, then the listener only accepts administrative requests from LSNRCTL running with the same OS credentials, or running as a local administrator (also referred to as super user).

Action: If an authorized user is attempting the command, then make sure that LSNRCTL is executed with the same OS user credentials as the running listener, or as a local administrator.

Unless you want to get into setuid wrappers, you need to have a password set for your listener. There's a good summary of how to set that up here, if you haven't already done so.

Then if you start the listener as normal as oracle, you can shut it down as user1 by going into the interactive mode of the controller, enter command 'set password', and enter the password for the listener:

$ lsnrctl

LSNRCTL for Solaris: Version 11.2.0.2.0 - Production on 12-NOV-2012 14:55:29

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> stop
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
TNS-01190: The user is not authorized to execute the requested listener command
LSNRCTL> set password
Password: <secret>
The command completed successfully
LSNRCTL> stop
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
The command completed successfully
LSNRCTL>

... and it should shut down. I know this is a different O/S and version but the principle is the same. And the reverse is true; if you start it as user1, you need to set password to be able to shut it down as oracle.

However, this is deprecated from 11gR2. The manual mentons using ssh or OEM, but you could also just make user1 switch to the oracle account to start and stop the listener via su. Obviously that gives them full DBA access, it isn't restricted to the listener, which is the case for ssh too.

I'm not sure why you'd want anyone you didn't trust to administer the database to be able to mess with the listener, or why you need to shut it down and start it up often enough for this to be an issue.

Improve this answer
6
  • I'll add that having multiple users being able to do this is bad, and might not be supported. Just thinking that it's the listener process that does a fork() (maybe exec, my memory is bad) to establish a dedicated connection and the resulting process connects to a big shared memory segment. Security problems abound if the permissions are set accordingly. Just a thought.
    – Philᵀᴹ
    Nov 13, 2012 at 1:32
  • @Phil - it is supported (or was, it's deprecated from 11gR2), but I originally had a comment querying why you'd want to do this, which I removed because I'd worded it unintentionally harshly. Agree that the security implications need to be given serious thought, but that's true for everything of course...
    – Alex Poole
    Nov 14, 2012 at 11:16
  • Thanks @AlexPoole , I think i'm just gonna use setuid. when i do chmod 6755 lsnrctl then user1 can stop listener if started by oracle (but not the inverse)
    – Ould Abba
    Nov 18, 2012 at 11:33
  • I wanted every body to be able to start and stop listener because i wrote some scripts witch changes the listener.ora and i want to restart the listener so changes will take effect for the rest of script.
    – Ould Abba
    Nov 18, 2012 at 11:37
  • Changing permissions on an Oracle-installed binary, or messing with the installation at all unless under direction from Oracle Support, isn't generally a good idea. Apart from anything else, the binary might be relinked by a patch. I was thinking more of a setuid wrapper, possibly just restricted sudo. Just out of interest, what are you changing in the listener.ora?
    – Alex Poole
    Nov 18, 2012 at 21:16
-2

Login as sysdba and run:

alter system set LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))' scope=both;

alter system register;

It worked form me.

Improve this answer
1
  • This doesn't answer the question. This just causes the instance to register with the listener but doesn't solve the problem how to restart the listener.
    – Colin 't Hart
    Jun 22, 2017 at 12:22
-2 
alter system 
    set LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))' scope=both;

alter system register;

worked for me too

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.