kill: <pid> : Permission denied.

[LawrenceLow]

Hi there,

We do have a script for our internal IT support team to terminate user's process (pid). It works previously and this morning our new SA delete the script accidentally. Unfortunately it doesn't work anymore after we do the restoration.

/user/livebgi% ll killer
-rwxrwxrwx 1 lowsyhtg informix 263 Jan 13 08:19 killer
/user/livebgi% more killer
#!/bin/sh
echo You are about to kill a user process, enter user to kill? Who is that lucky person?
read usr_name
a=`ps -ef|grep "$usr_name"|grep -v grep|grep -v ps|cut -c10-14|sort -r`

echo Killing the process belongs to user $usr_name:$a
kill -9 $a

#!/bin/csh
/user/livebgi%
/user/livebgi% finger | grep ycchong
ycchong Chong Yew Choun *t9e 4:14 Thu 08:37 Marketing
/user/livebgi% killer
You are about to kill a user process, enter user to kill? Who is that lucky person?
ycchong
Killing the process belongs to user ycchong:19800 19797 18350 18088
kill: 19800: Permission denied.
kill: 19797: Permission denied.
kill: 18350: Permission denied.
kill: 18088: Permission denied.
/user/livebgi%




Please assist!!

[Jupinder Bedi]

change the ownership of the script to root by using chown command and try ... best of luck

[LawrenceLow]

Jupinder,

/user/livebgi % ll killer
-rwxrwxrwx 1 root sys 263 Jan 13 08:19 killer
/user/livebgi % killer
You are about to kill a user process, enter user to kill? Who is that lucky person?
lowsyhth
Killing the process belongs to user lowsyhth: 4176
kill: 4176: Permission denied.
/user/livebgi %


still remain the same....

[Horia Chirculescu]

Lawrence,

I suppose that you run this script as root, right?

Horia.

[Jupinder Bedi]

are you using the root user normal user to kill the processes. if you are using normail user you cant kill the processes unless or until you have root permission otherwise you need to use the sudo

# ./killer
$ sudo ./killer

[Vishu]

Hi,

you must be root user to kill the process. so, try login with root and killing those processes.

Thanks

[LawrenceLow]

Nope, previously we can to use Informix user to kill the process. In fact, the script is mainly for our internal IT support team to kill the normal user's process.

[Horia Chirculescu]

You can do it 2 ways:

1. modify your script tu use sudo in order to send the kill command

or

2. modify your "normal" user setting user id=0 in /etc/passwd

Maybe you used the second 'solution'

Best regards
Horia.

[Vishu]

Lawrance,

one user cannot kill any process initiated by the other user or you have to be super user for that.

[Pete Randall]

Try setting it up like this:

-rwsr-xr-- 1 root informix 1280 Feb 22 2005 killer


Pete

[Dennis Handly]

>a=`ps -ef|grep "$usr_name"|grep -v grep|grep -v ps|cut -c10-14|sort -r`

You can optimize this to make it safer.
a=$(ps -fu $usr_name | cut -c10-14 | sort -r)

You can get ps(1) to provide the column you need so you don't need cut(1).
a=$(UNIX95=EXTENDED_PS ps -u $usr_name -opid= | sort -r)

>kill -9 $a

Probably better to do a normal kill before you do a kill -9.

[Steven Schweda]

> [...] after we do the restoration.

Who did "the restoration", how?

> Try setting it up like this:

It's easy to lose an "s" like that, if "the
restoration" is not done by "root", or it's
not done carefully. With good reason, the OS
is not eager to let just anyone set an
SUID/SGID flag (or arbitrary owner/group) on
a file.

> -rwsr-xr-- [...]

And with that "s" there, you don't want a "w"
anywhere else, either. (Unless you're
_looking_ for trouble.)

[James R. Ferguson]

Hi:

I agree with Pete insofar as this would appear to be the loss of the 'setuid' bit and the ownership by 'root' during file restoration.

If that's true, and restoring these settings fixes your problem, I suspect that your operating system release may be pre-11.23. The 'setuid' bit isn't normally honored on shell scripts at that level unless you alter the kernel 'secure_sid_scripts' parameter.

As noted, 'setuid' scripts are potentially very dangerous from a security standpoint. You can create a C-wrapper and set the 'setuid' bit on that; or use SUDO (as already suggested) as you move forward.

Whatever you do, do NOT established multiple uid=0 accounts. This is an accident waiting to happen when you one day remove the account with a uid=0 thinking that it isn't 'root'. It's the uid=0 that equates to 'root' whatever the name is.

Regards!

...JRF...

[Pete Randall]

> And with that "s" there, you don't want a "w" anywhere else, either

Are you saying that the "w" for owner is a problem? I must be missing something (I do that every once in a while, especially as I get older) because I can't see how that would be an issue.


Pete

[Pete Randall]

Or are you saying "anywhere else" other than owner?


Pete

[Steven Schweda]

> Or are you saying "anywhere else" other
> than owner?

I thought that "anywhere else" meant anywhere
else, that is, in some other place, where
"other", here, means other than where it was
shown.

Clearer?

[James R. Ferguson]

Hi:

> Pete: Are you saying that the "w" for owner is a problem? I must be missing something (I do that every once in a while, especially as I get older) because I can't see how that would be an issue...Or are you saying "anywhere else" other than owner?

I don't view leaving the owner permissions with "w"rite access in this case to be a problem. After all, in this example, 'root's the owner and it doesn't matter.

Personally, I like to remove write permissions from most scripts entirely and only override a 'vi' edit of them with a 'wq!'.

Conferring write permission to anyone else other than the owner (i.e. to the group or to the world) would, of course, be a hugh security risk. Anyone could adapt the script to his or her needs!

Regards!

...JRF...

[Pete Randall]

Steven> Clearer?

Totally transparent - thanks!


Jim, thanks for the confirmation. I wasn't reading Steven's comments correctly and thought there was some facet of permissions that I'd missed way back in "Intro To HP-UX".


Pete

[LawrenceLow]

The problem has been resolved by changing permission.

-r-sr-xr-x 1 root bin 263 Jan 13 08:19 killer