Re: Stopping java based applications
Erik N Johnson wrote: This is generally considered highly insecure. The usual caveat about running userland apps as root. In fact, the generally accepted practice amongst most Linux admins is: ALWAYS issue administrative commands using sudo. This and Everything Erik says is True. I posted in the vein of "answer the question asked first, thus gaining cred for the lecture you intend to follow up the answer with". -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
This is generally considered highly insecure. The usual caveat about running userland apps as root. In fact, the generally accepted practice amongst most Linux admins is: ALWAYS issue administrative commands using sudo. NEVER log in remotely as root. ONLY log in as root w/ physical access, and ONLY if something is wrong with your sudo config. If you use these policies the root password will never be issued except on a physically secure serial line or other local bus connection, and you will never have to run even so much a s a shell as root. This is good for a variety of reasons that it is not really necessary to expound here. Basically just remember, setuid root == VERY INSECURE. Setuid anything else is really only used to give daemons access to the vfs resources they need and nothing else. Sudo is specifically designed as an answer to specifically the type of problem you are encountering here. Sudo is your friend. Sudo should ship with SLES AND RHEL. I don't recommend this on enterprise servers but some Linux distros even disable the root user by default (this is done with the lock option of the passwd command, i.e. passwd -l root. That command WILL break your system is not executed by a properly configured sudo command, 100% of the time.) Sudo is better than being root. always. Sudo is better than setuid for almost everything as well. USE SUDO!!! Erik Johnson On Tue, Mar 31, 2009 at 10:48 AM, Jack Woehr wrote: > CHAPLIN, JAMES (CTR) wrote: >> >> -r--rwsr--+ 1 user group 500 Jan 21 16:23 stopServer.sh >> The setuid is set on group level. >> > > It has to be setuid to root because only root can send signal > to other user's processes. So it has to be owned by root and > should be something like -r-sr-x--- > > Oh, minor terminological pedanticism: when the set is on the group we call > it setgid to differentiate from setuid. > > -- > Jack J. Woehr # I run for public office from time to time. It's > like > http://www.well.com/~jax # working out at the gym, you sweat a lot, don't > get > http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
I tend to agree that sudo is a much better way of accomplishing this, you can embed sudo in scripts as long as the script is called interactively. Thus it would be very simple to get some info about the process in question (specifically uid) from either the ps command or the /proc directory (every process is represented by a directory immediately below /proc bearing a name which is a decimal string equivalent to the pid. The proper ps incantation is: ps p [pid] o euid="" The null string ensures that only one line with the required uid is specified (i.e. takes out the column header). Alternatively the o option may take a key-value along the lines of ruser="" to return the human-readable username. Sudo will happily except either uid or username as the user argument. So if you do: PID = pgrep [progname] UID = ps p $PID o euid="" sudo -u $UID kill -15 $PID and sudoers is properly configged you should be good unless pgrep returns more than one pid, in which case you need a way to specify whch instance you want to kill, perhaps you can simply omit tat step and supply the pid directly as the first positional parameter. The more complex thing will be to ensure that all the users in question have proper sudo permissions. It is VERY possible to specify exactly which commands a user may execute as another user. I.e. for the group of users{ bill, fred, ted, joe } and the group of applications { appA, appB, appC } it is possible to specify that bill ma execute all three apps as each of the other three users, fred can execute only appB as bill, ted can execute apps A and C as fred and joe, and joe has no permission to execute any of A,B, or C as anybody but himself. The syntax for doing this is described in the visudo man page. WARNING!!! Do NOT attempt to edit the /etc/sudoers file by any other means than executing visudo. This is required in order to ensure the sudoers database is consistent with the flat config file. As a supplement to the visudo and sudo man pages, you may also want to read one of the many many sudo tutorials out there. Iirc the gentoo forums sudo how-to is very straight-forward and applies to pretty much any sudo installation anywhere. If your local installation differs in any way it will most likely be in the pathname to the sudoers config file (typically /etc/sudoers) and it will be clearly noted in the man page. Hope that helps, Erik Johnson On Tue, Mar 31, 2009 at 10:10 AM, CHAPLIN, JAMES (CTR) wrote: > -r--rwsr--+ 1 user group 500 Jan 21 16:23 stopServer.sh > The setuid is set on group level. > Removed the user execute perms as shown above, and script failed to > "kill -p pid", got permission denied message still. > > Did a chmod 2474 stopServer.sh to set the bits, is this correct in what > you are suggesting? > > James Chaplin > Systems Programmer, MVS, zVM & zLinux > Base Technologies, Inc > > -Original Message- > From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of > Jack Woehr > Sent: Tuesday, March 31, 2009 10:28 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: Stopping java based applications > > CHAPLIN, JAMES (CTR) wrote: >> We want anyone in the group level to be able to also issue >> the kill command (in the script). Is there a way to allow users in a >> group to kill each other's started processes. >> >> > You can have a script or program > > * with the setuid bit set > * with the write permissions off > * with group execute perms but no user execute perms > > -- > Jack J. Woehr # I run for public office from time to time. > It's like > http://www.well.com/~jax # working out at the gym, you sweat a lot, > don't get > http://www.softwoehr.com # anywhere, and you fall asleep easily > afterwards. > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
Mark Post wrote: Oh, minor terminological pedanticism: when the set is on the group we call it setgid to differentiate from setuid. Hardly minor, since the behavior it enables is completely different from setuid. True, but I was trying not to be /breathless/ about it, just hinting to the poster that he should dig in that direction for more info. -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
>>> On 3/31/2009 at 11:48 AM, Jack Woehr wrote: -snip- > Oh, minor terminological pedanticism: when the set is on the group we call > it setgid to differentiate from setuid. Hardly minor, since the behavior it enables is completely different from setuid. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
CHAPLIN, JAMES (CTR) wrote: -r--rwsr--+ 1 user group 500 Jan 21 16:23 stopServer.sh The setuid is set on group level. It has to be setuid to root because only root can send signal to other user's processes. So it has to be owned by root and should be something like -r-sr-x--- Oh, minor terminological pedanticism: when the set is on the group we call it setgid to differentiate from setuid. -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
Re: how to cause a Java app to shutdown IF you have the authority to send it a signal: Java JVMs on *nix generally will respond to SIGINT (2) or SIGTERM(15) by exiting "normally". An application an register a "shutdownhook" and run some code to clean up if necessary. Here's a link: http://www.ibm.com/developerworks/java/jdk/linux/50/sdkandruntimeguide.lnx.html#signals Kirk Wolf Dovetailed Technologies On Tue, Mar 31, 2009 at 8:50 AM, Scott Rohling wrote: > IMO - the java app should provide a way to tell it to exit gracefully - and > the stop script would exercise that. > > Scott > > On Tue, Mar 31, 2009 at 7:43 AM, CHAPLIN, JAMES (CTR) < > james.chap...@associates.dhs.gov> wrote: > > > Our programmers have been creating java based applications that they > > start and stop using simple scripts. The start script call java to start > > the program; however the stop script issues a simple kill command > > against the PID. > > > > Our problem if User A start the program, only User A can kill it (except > > for root). We want anyone in the group level to be able to also issue > > the kill command (in the script). Is there a way to allow users in a > > group to kill each other's started processes. > > > > Being new to the zLinux and Java worlds, is it standard to issue a 'kill > > -9 pid" to terminate a java program? Is there a better way and how does > > issuing a kill de-allocate memory and other issues? > > > > James Chaplin > > Systems Programmer, MVS, zVM & zLinux > > Base Technologies, Inc > > Supporting the zSeries Platform Team > > > > -- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
-r--rwsr--+ 1 user group 500 Jan 21 16:23 stopServer.sh The setuid is set on group level. Removed the user execute perms as shown above, and script failed to "kill -p pid", got permission denied message still. Did a chmod 2474 stopServer.sh to set the bits, is this correct in what you are suggesting? James Chaplin Systems Programmer, MVS, zVM & zLinux Base Technologies, Inc -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Jack Woehr Sent: Tuesday, March 31, 2009 10:28 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Stopping java based applications CHAPLIN, JAMES (CTR) wrote: > We want anyone in the group level to be able to also issue > the kill command (in the script). Is there a way to allow users in a > group to kill each other's started processes. > > You can have a script or program * with the setuid bit set * with the write permissions off * with group execute perms but no user execute perms -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
On Tuesday 31 March 2009 09:43, CHAPLIN, JAMES (CTR) wrote: >Our programmers have been creating java based applications that they >start and stop using simple scripts. The start script call java to start >the program; however the stop script issues a simple kill command >against the PID. > >Our problem if User A start the program, only User A can kill it (except >for root). We want anyone in the group level to be able to also issue >the kill command (in the script). Is there a way to allow users in a >group to kill each other's started processes. Not directly, because the kill(2) system call does not permit a signal to be sent to processes unless the calling user is also the process owner (or the superuser). But see below for a work-around. >Being new to the zLinux and Java worlds, is it standard to issue a 'kill >-9 pid" to terminate a java program? Is there a better way and how does >issuing a kill de-allocate memory and other issues? No. Using "kill -9" is the "kill of last resort" method. You should first do a "kill -15" to send a SIGTERM signal, which is the polite way to ask the program to terminate. This gives the program the opportunity to shut itself down gracefully by catching the signal and handling it. The "kill -9" sends a SIGKILL which cannot be caught or ignored. The process is immediately halted by and destroyed by the kernel; the program never gets a chance to do anything. Resources (open files, memory, etc.) is cleaned up by the kernel, so you're OK there, but any program state information is lost. The standard way to kill off a program is to send it a SIGTERM, wait several seconds for it to shut itself down, then send it a SIGKILL. This is what the system shutdown scripts do when halting or rebooting Linux. Now for the work-around I mentioned. Scott has the right idea: the Java app should provide a way for an external program to tell it to stop. If it does, use that. Sometimes it is done by starting up another JVM to send the first one a command via some IPC mechanism (eg. a socket). I think this is what WebSphere does. Or it is done by sending some signal (usually SIGTERM) to it, like I mentioned. But how to get the group-level control you originally asked about? If you can send a command via IPC to stop it, then you just make the program that sends that command executable only by users in that group. If you have to send a signal, it is trickier, because as the good book says: "For a process to have permission to send a signal it must either be privileged (under Linux: have the CAP_KILL capability), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process." So the program that sends the signal must be run as either the same user that started your java app, or the superuser. It sounds like any user in the group can start the program, so you write a program that is SetUID to root: it runs as the superuser regardless of who invoked it. You can't do that with a shell script, but I think you can with PERL. Make it owned by root, and your group, with permission mode 4750 (SetUID, read-write-execute by user, execute by group, no access to anyone else). That script finds the correct PID then does its "kill -15" as root, which will send the SIGTERM to that process. - MacK. - Edmund R. MacKenty Software Architect Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.4321 Email: m...@rs.com Web: www.rocketsoftware.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
>> Our programmers have been creating java based applications that they >> start and stop using simple scripts. The start script call java to start >> the program; however the stop script issues a simple kill command >> against the PID. Ugh. Wrong, wrong, wrong, unless they have set up their application to capture something like SIGSTOP and die gracefully. >> Our problem if User A start the program, only User A can kill it (except >> for root). We want anyone in the group level to be able to also issue >> the kill command (in the script). Is there a way to allow users in a >> group to kill each other's started processes. Sudo. It's not just for operators any more. >> Being new to the zLinux and Java worlds, is it standard to issue a 'kill >> -9 pid" to terminate a java program? Absolutely not. Kill -9 is NEVER supposed to be used to normally exit an application. It's "terminate with extreme prejudice". Not a normal exit. >> Is there a better way Have the application set up a signal handler for SIGTERM or SIGUSR2 that triggers a normal termination, or engineer a normal shutdown message into the application. >> and how does >> issuing a kill de-allocate memory and other issues? Indeterminate. Kill -9 ends the application immediately with no chance of cleanup. It could get lucky and do no harm, or you could wedge something important that will require a full reboot (stuck semaphores and shared memory regions getting locked are common side effects). Most modern Unixen try to clean up as best they can after a SIGKILL, but it's never good practice to rely on that. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
CHAPLIN, JAMES (CTR) wrote: We want anyone in the group level to be able to also issue the kill command (in the script). Is there a way to allow users in a group to kill each other's started processes. You can have a script or program * with the setuid bit set * with the write permissions off * with group execute perms but no user execute perms -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Stopping java based applications
IMO - the java app should provide a way to tell it to exit gracefully - and the stop script would exercise that. Scott On Tue, Mar 31, 2009 at 7:43 AM, CHAPLIN, JAMES (CTR) < james.chap...@associates.dhs.gov> wrote: > Our programmers have been creating java based applications that they > start and stop using simple scripts. The start script call java to start > the program; however the stop script issues a simple kill command > against the PID. > > Our problem if User A start the program, only User A can kill it (except > for root). We want anyone in the group level to be able to also issue > the kill command (in the script). Is there a way to allow users in a > group to kill each other's started processes. > > Being new to the zLinux and Java worlds, is it standard to issue a 'kill > -9 pid" to terminate a java program? Is there a better way and how does > issuing a kill de-allocate memory and other issues? > > James Chaplin > Systems Programmer, MVS, zVM & zLinux > Base Technologies, Inc > Supporting the zSeries Platform Team > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Stopping java based applications
Our programmers have been creating java based applications that they start and stop using simple scripts. The start script call java to start the program; however the stop script issues a simple kill command against the PID. Our problem if User A start the program, only User A can kill it (except for root). We want anyone in the group level to be able to also issue the kill command (in the script). Is there a way to allow users in a group to kill each other's started processes. Being new to the zLinux and Java worlds, is it standard to issue a 'kill -9 pid" to terminate a java program? Is there a better way and how does issuing a kill de-allocate memory and other issues? James Chaplin Systems Programmer, MVS, zVM & zLinux Base Technologies, Inc Supporting the zSeries Platform Team -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390