Operating System - HP-UX
1832645 Members
2903 Online
110043 Solutions
New Discussion

Re: OS directories ownership

 
john123
Trusted Contributor

OS directories ownership

Hi All
Am facing some difficulty while installing a software in HP UX 11.23.A remedy provided for this by the software vendor is to change the ownership and permissions of the directories as below

/ - root:sys (roor:root), 0755
/opt - root:sys (root:root), 0755 or 0555
/var - root:sys (root:root), 0755 or 0555
/var/opt - root:sys (root:root), 0755 or 0555
/etc - root:sys (root:root), 0755 or 0555 (0555 is preferred)
/etc/opt - root:sys (root:root), 0755 or 0555

What all are the pros and cons of changing the OWNERSHIP of these directories from the default values
8 REPLIES 8
Andres_13
Respected Contributor

Re: OS directories ownership

Unpredictable things can happen if you do that. Look my server config:

/ -> i can't see with a "ll"
/opt -> bin:bin -> 555
/var -> bin:bin -> 555
/var/opt -> bin:bin -> 555
/etc -> bin:bin -> 555
/etc/opt -> bin:bin -> 555

You can try at your own risk. If so, first thing to do is a ignite backup and also backup all your data.

But i think that if you change the ownership & permmisions to root:root nothing will be able to make nothing in your server.

Regards.
TTr
Honored Contributor

Re: OS directories ownership

> from the default values

The 0755 and/or 0555 are the default values. What were they set to?

Is this some kind of an extremely restricted os environment and app? I don't see what difference the root:root change would make for an app. What kind of app is it and what was the justification?
john123
Trusted Contributor

Re: OS directories ownership

Here is my current ownership

drwxr-xr-x 20 daemon daemon 8192 Mar 7 09:49 /
dr-xr-xr-x 32 bin bin 8192 Mar 7 09:08 /etc
dr-xr-xr-x 24 bin bin 8192 May 28 2007 /etc/opt
dr-xr-xr-x 84 bin bin 8192 Mar 7 09:49 /opt
dr-xr-xr-x 24 bin bin 8192 Mar 7 09:49 /var
dr-xr-xr-x 30 bin bin 8192 Sep 21 10:48 /var/opt
TTr
Honored Contributor

Re: OS directories ownership

Again I would question the app people for the change request and the reasoning behind it. Is it verified for an HP-UX environment? Or because of a minor glitch they compared it with another UNIX and are asking for these?

For example if /etc/somefile.conf if 644 (-rw-r--r--) and /etc is either 755 or 555, the file is readable by everybody. And the same is true for executable files with 755 instead of 644.

I have seen many app "specilists" come in to our site to install their apps and with very few exceptions they are mediocre at best.
Bill Hassell
Honored Contributor

Re: OS directories ownership

Unless you want a very long and thankless job trying to fix all the problems caused by changing OS ownerships and permissions, run the swverify command to report on all the mistakes, then fix them. You app vendor is violating security standards set by the manufacturer (HP) and therefore auditors could rightfully shutdown your system as being compromised.

Under NO circumstances do I ever allow an application to be loaded that requires changing OS directory and mountpoint ownerships and permissions. It means that the application is very poorly designed and possibly implies poor performance even after it is loaded.

OS directories for HP-UX have been set after more than 20 years of experience. They should never be changed without HP's recommendation.


Bill Hassell, sysadmin
john123
Trusted Contributor

Re: OS directories ownership

Thanks everyone for your reply.

Let me rephrase my question. Lets forget about the application for the time being and focus on the pros and cons of changing the ownership. I have heard from a security expert that keeping the default ownership of daemon:daemon and bin:bin for these mount points is a BAD security practice. But didn't get any convincing reasons from him. The reason of this post is to explore the security threats of keeping it to the default or the advantages/disadvantages of changing them to root:root.

I would really appreciate, if all the GURUs in this forum can shed some light on this.

Thanks in advance,
John
Kapil Jha
Honored Contributor

Re: OS directories ownership

file ownership and permission are just a way to keep some unwanted user to do nasty thing on server.
I think root:root or root:sys wont affect anything but permission would affect a log.
Consider
root:root 755/555
means root can rwx any file , users belong to group root (only root by default) can rx ,other (means anyone) can rx and this calls the trouble.Any user can run any script and this is not any sys admin wants.

second root:sys same this as above only users in sys group can rx but others permission if 5 is making everything waste here.

so you can check /etc/group for various groups bin,daemon,uucp etc and check users of them. Here permission should be given after serious thought.

Here 755 is crap 750 should do I suppose , again it depends on application,.

Hope this help.
BR,
Kapil
I am in this small bowl, I wane see the real world......
Heironimus
Honored Contributor

Re: OS directories ownership

You probably didn't get any convincing reasons from the security expert because he was probably repeating what he heard somewhere else without fully understanding it. That happens a lot.

If you run processes as "bin" or "daemon" they could potentially modify or change the permissions on files/directories owned by that user. However, on current systems I usually see a lot more processes running as root than as bin or daemon, which is a far greater potential risk.

A larger issue is that changing ownerships and permissions from HP's standard is likely to create problems when you open support calls. You really don't want HP to say "reinstall the OS" and hang up on you. Run swverify to make sure your current ownerships and permissions are right and never change them without an extremely good reason.

And, lastly, as a "fix" those ownership changes sound more than a little silly. The only real way I see that fixing anything is if the vendor hard-coded an ownership check in to the app. That would be wrong on many levels.