User can't stop Oracle listener (TNS-01190)
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&gt; stop
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
TNS-01190: The user is not authorized to execute the requested listener command
LSNRCTL&gt; set password
Password: &lt;secret&gt;
The command completed successfully
LSNRCTL&gt; stop
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
The command completed successfully
LSNRCTL&gt;


... 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.