permissions problem after converting to a trusted environment

[Nick D'Angelo]

HPUX 11i
RP2470

Last week, I converted to a Unix trusted model for my production server. it does not use DNS or NIS. We converted so that we can utilize the enhanced security options.

It went generally quite smoothly, however there appears to be one major pain that I am working through.

previously, when a user created a file it was RW RW RW by everyone.

Now, they are only RW by the user that created the file with our application, which is Progress Based.

We have procedures and processes that rely on the data being RW RW RW and they are failing.

Any ideas?

is it the default Umask? I am getting tired of fixing the problems one by one, hence the reason for this posting for a speedy answer, which I have become so accustomed to as the solutions are usually out there somewhere.

Thanks in advance,

nickd

[A. Clay Stephenson]

When a file is created there are two things at play. The mode of the file and umask. When the file is created with mode 666, umask then "subtracts" from this value. It actually isn't subtraction but you can thing of it that way. What you should do is:
umask
before invoking your application and note the value. You should be able to find it in /etc/profile or the user's .profile OR in the script that is invoking a command. The last umask (even those within an apllication) wins. Did you by any chance run Bastille to harden your system at the same time?

In any event, setting files to 666 is very poor practice and you are going to get clobbered by your security auditors. A better option is to get your required user into groups (or multiple groups using /etc/logingroup) so that the applications run with restricted permissions.

[Nick D'Angelo]

Clay thanks.

From my prompt, I type in umask and it returns 077.
I touched a noname file and it was RW- --- ---

But I need this changed to RW- RW- ---

Thanks,

Nickd

[Nick D'Angelo]

Clay thanks.

From my prompt, I type in umask and it returns 077.
I touched a noname file and it was RW- --- ---

But I need this changed to RW- RW- --- and not RW by everyone as I previously mentioned.

Thanks,

Nickd

[A. Clay Stephenson · Accepted solution]

Okay,in that case, start by looking in /etc/profile for a umask setting. It's probably set to 077; change it to 007 -- still not a great value but MUCH better than 000. Next check your .profile to see if there is a umask call there. I am assumming you are running /usr/bin/sh as your shell. Tc shell, for example, uses .cshrc. Note that there could be files sourced by /etc/profile and/or .profile so you will need to step throurg them if the fix is not obvious. This should be rather simple to track down.

[Jeff_Traigle]

The default umask is 000 (see umask(1)). Typically, the umask is set for interactive sessions in /etc/profile to provide site-specific system-wide defaults. Each user can set their own umask in ${HOME}/.profile for user-specific interactive sessions. Additionally, individual scripts can set the umask for application-specific umask requirements and to assure they are set appropriately for non-interactive sessions. It sounds like the umask got changed somewhere in these areas on your system, but I've never heard of converting to a Trusted system doing that.

[Patrick Wallek]

Find where the umask is set, /etc/profile or ~/.profile for the user and try changing the umask to 017.

[Nick D'Angelo]

After some testing on my test server, in reading Clay's post and others on the forum, I added a umask command to the /etc/profile - to be exact.

umask u=rw,g=rw,o=

I then logged on an average user and did a umask and it was 0117

I created a dummy file once again and it was RW- RW- ---.

This will suffice as my users are forced into our ERP application when they logon.

Did I miss anything?

Thanks.

[Patrick Wallek]

You must now try creating the files from within your application and verify that they have the correct permissions. It is possible that the application can play with the umask as well.

[A. Clay Stephenson]

That will probably do it but remember if any users have a umask setting in their .profile's that the last umask wins.