allow a non-root user to use fuser

[Marc Ahrendt]

here is what i see on my 11i system
ls -al /etc/fuser /usr/sbin/fuser
lr-xr--r-T 1 root sys ... /etc/fuser -> /usr/sbin/fuser
-r-xr--r-- 1 bin bin ... /usr/sbin/fuser
NOTE: the "..." implies stuff not inluded from the ouput from ls

basically i have 2 questions
1) why does the link have the "lr-xr--r-T" permissions?
2) what are the impacts of running "chmod 555 /usr/sbin/fuser"?
a non-root user wants to run fuser but my concern is giving them the ability to kill proccesses that they do not own

[Patrick Wallek]

What are they trying to do? Could the same thing be accomplished with lsof?

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/lsof-4.70/

lsof can compiled so that non-root users can ONLY see their own open files. As far as I know lsof does not have any options like the '-k' option to fuser so they shouldn't be able to kill others processes.

[Marc Ahrendt]

i do have lsof installed but its compiled with the HASSECURITY defined ...which only allows users to see PIDs owned by that same user running the lsof command

i guess i could reinstall it but i am interested in knowing the impact of tweaking the permissions on /usr/sbin/fuser ...my gut feeling is that it is OK to use 555 and that the user will not be able to kill PIDs owned by other users via the "-ku" option

also i think the link permissions are bogus/irrelevant ...and most likely relate to legacy HP-UX stuff (T => a "transition link")

[Steven E. Protter]

I'm not sure tweaking the permissions on fuser will help a whole lot.

If you let other users execute it, they still won't be able to kill processes other than their own. If thats enough, it might help.

If they need to be able to kill all processes on say a filesystem they don't own, then the program would need suid capability. That would be like giving the users explosives and inviting them to blow up your system.

SEP

[Marc Ahrendt]

i changed the permissions to 555 on /usr/sbin/fuser so that people can see all the relevant PIDs ...and i verified that they only will have the power to kill just the PIDs they own

i also have lsof but with the HASSECURITY defined users can only see their PIDs and not others for the specified file/directory

i generally do not use setuid scripts and often use sudo with user specific stuff in /etc/sudoers

i do have issues here with users wanting to be root ...its a constant battle where i must have already repeated/explained the concept of not needing to be root so many times

thx patrick and steve

[Bill Hassell]

Note that symink (transition link) permissions have no effect on the target. Changing fuser to 555 seems to work OK, but I am always leary of changing opsystem programs and files...I don't have time to test every script and executable and I/O combination to truly verify everything still works OK. On the surface, it would appear that 55 is OK.

But for safety, I would install sudo and then give wanna-be sysadmins a couple of commands with limited parameters.

[A. Clay Stephenson]

The sticky bit on symbolic link is often used by the software install process as a flag. File modes on symbolic links really have no importance; only the mode of the file pointed to counts.

While non-root users will not be able to kill processes other than their own, by setting the execute bit for group and other, non-root users can gain knowledge about other processes so from that perspective it is a security risk though not a big one.

[José Enrique González]

Hi:

Yo could install and configure "sudo" to acomplish this. sudo uses a configuration file (sudoers) to tell explicity who can run which commands as root. Once configured, user could execute fuser command with something like:

sudo /usr/sbin/fuser

You even can configure the exact syntax de user can invoke, so you could for example deny a non.root user form using -k option for fuser

[Geoff Wild]

I think you can use sudo for this or perhaps even with Restricted SAM.

Sudo:
http://hpux.ee.ualberta.ca/hppd/hpux/Sysadmin/sudo-1.6.7p5/

Rgds...Geoff

[rmueller58]

644 is a common file permission for executables that are restricted use.
the impact of 555 is a security issue.

add your non-root user to the /etc/sudoers
and
execute the command
sudo -u root (or superuser) command string

We have some scripts that sudo to a DBA account to build databases

[Michael Mann]

The following patches fix this:

PHCO_29348 (11.00)
PHCO_29349 (11.11)

These change the permissions to 555. Even
though a non-root user can execute the
command with -k, they won't be able to kill
anything they don't have priviledge to kill.
No error will be reported in such a case,
though...they'll just get the prompt back,
but nothing will have been done.