kill: <pid> : Permission denied.

[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