umask

[jerry1]

Why can I not set the umask so that when
creating files they come out as 775 rwxrwxr-x.

I know historically that umask 022 would result
in drwxr-xr-x and files would be rw-r--r--.

And that you do not want files to be executable
is they don't need to be since accidentaly
running a file that should not be executable
could be undesirable.

[Rodney Hills]

Didn't you just answer your own question?

-- Rod Hills

[RAC_1]

You can not set a umask that would set exectable perms for a file/dir.

Anil

[A. Clay Stephenson · Accepted solution]

There are two components at play here and you only have control over one --- at least from the shell.

When a file is created it is given a mode and then umask "subtracts" from the mode value to yield the actual mode. (It's not really subtraction but you can kinda, sorta think of it as subtraction.) The shell uses a mode of 666 for regular files and 777 for directories. This means that under the shell, a two-step process is required. You first create the file and then do an explicit chmod command to set whatever bits you want.

Under Perl or C, you are allowed to specify the mode and umask when you creat a file but under the shell you only can set umask.

[jerry1]

That's what I've always understood that
you can't set the file execute by some
variation of umask. But I have an oracle dba trying to do so.

And why does the man page show you can or
am I just reading it wrong?

Not that I trust the man pages entirely.

[Patrick Wallek]

I see what you mean about the man page. It is very misleading.

With the normal shell, it is not possible to have a file created with 777 permissions. You will have to manually set the execute bits.

Unless the file is a script or program, it doesn't really need the execute bit anyway.

[A. Clay Stephenson]

It would help if you indicated which man page but I assume you are referring to (1) umask. In this case, the man page is quite correct.
"The umask command sets the value of the file mode creation mask or displays the current one. The mask affects the initial value of the file mode (permission) bits for subsequently created files."

The key word in the man page is 'affects'. This should be read as 'alters' rather than 'sets'. Again, there are two things at play and umask is only one of them.

For a really good explanation, man 2 open and look at the section that mentions O_CREAT. Under the shell, keep in mind that the default mode for regular files is 666 when you read the open man page.

You question is a good example of why every admin should be familiar with every system call and have at least a little programming background. That way, you can defeat those pesky dba's with words rather than resorting to baseball bats.

[jerry1]

It's a sad day here for Systems
Administration. The DBA's have been given
root on the boxes since they seem to
believe they need it to manage oracle.
Despite my efforts to explain to management
that they don't and that with proper
permissions and owner/groups set they would
be able to manage oracle fine without it
like other companies.

Let the games begin!

Anyone hiring in Dallas?

Thanks for all your inputs.

[jerry1]

Clay, I cannot find any references to
what you stated. I know from experience
that you cannot set execute perms with umask
on files just dirs. But I can't seem to
explain it to the DBA and she does not
believe it due to the wording in the man
page. They think I have somthing set on the
server preventing them from doing something
that they need to do with chmod if they want
execute perms.

[A. Clay Stephenson]

Okay, I'll try one more time. This is a direct quote from the (1) umask man page.

"The umask command sets the value of the file mode creation mask or displays the current one. The mask affects the initial value of the file mode (permission) bits for subsequently created files."

The creation MASK is not the same as the creation MODE --- and that is where the confusion is coming in.

Here's what really happens:
Let's suppose your umask is 022 (000010010).
Now, let suppose that the application (e.g. the shell, SQLPlus, etc.) specifies a creation mode of 666 (110110110). The actual mode is done thusly:
Inital Mode xxx: 110110110 (666)
Umask xxxxxxxxx: 000010010 (022)
Umask inversion: 111101101 (flip every bit)
--------------------------
Actual Mode xxx: 110100100 (644).

The actual mode is the result of the AND'ing of each bit in the creation mode with the corresponding bit in the inverted umask. This is exactly what the umask man page is trying to tell you.

The real solution to your "problem" lies not in umask but rather in the source code of the application (e.g. the shell, SQLPlus, etc.) because that is where the creation mode subsequently altered by umask is set.

I suppose you could get the source code to a shell and modify it to your liking and then install it but a far better answer is to learn Perl. You can do this all in one shot there. I really don't understand the difficulty in creating a file and then issuing a chmod OR creating the file and executing via "sh myfile arg1 arg2". That will work even if the execution bit is not set.

[Bill Hassell]

And I would be VERY concerned about the DBAs wanting to create files with 775 permissions. Way too many DBAs and wannabe SysAdmin who just read the "Unix for PC Users" feel that *all* their problems will be solved with 777 permissions rather than determine the real reason for "permission denied" messages. A data file should *NEVER* have an execute bit set--it is very bad practice. A directory is actually executed when it is searched but an Oracle data file (index, log, etc) should never have an execute bit.

Since this concept is so basic to Unix sysadmin, I would insist that your manager send your DBAs to a couple of HP classes, indicating that all HP-UX sites will not allow anyone to have the root password unless they have gone to two weeks of training. (I'm exaggerating for emphsis) REMEBER: system crashes and other "oops" problems caused by amateur sysadmins with root will be blamed on you, not the DBAs.

And just to let you know, there are thousands of Oracle installations running HP-UX where DBAs never get the root password. You might suggest that if DBAs get the root password, then all sysadmins get full data management privileges for all the databases.

[jerry1]

Thanks, Clay. This is what I had sent:

Your file "test" already exists. remove it and recreate it. umask will not change
the perms on existing files. touch does not change perms on existing files.

# umask 022

# umask
022

# touch testfile

# ll testfile

-rw-r--r-- root sys 0 May 4 15:19 testfile


-rw-r--r-- is mode 644.

Umask 022 on default mode(666) for files.

666
-022
------
644 - rw-r--r--

You cannot set execute perm on a file within a shell with umask.

[jerry1]

I hear you Bill. The DBA's had their umask
set to 007 which caused some problem with
tnsnames.ora being rw-rw---- when they updated it via rm first then copy. It use
to be rwxrwxr-x according to Tripwire.

They do practice the 777 technique.

"Gee, It won't run. chmod -R 777 /opt/oracle.
There. Now I don't need root or oracle ID."

I am not an oracle dba but do you need root
to install oracle. It looks like they are
installing it with oracle ID. And I heard
something about root.sh that oracle has that
I need to check on. They have no respect for
Administration and they have it in their
mind that they can do it better.
One has a GED and the other has a BS in
General Education. How ironic.

[Bill Hassell]

Just wait 'till one of them logs in as root (and the $HOME directory is / - a very bad idea) and they do something like this:

cd /opt/orcle
sh: /opt/orcle: not found.
chmod -R 777

Or the (in)famous membership in the rm -r * club:

cd /temp
sh: /temp: not found.
rm -r *

If you search the ITRC forums, you'll see several posts asking for help to fix the total mess that either of the above commands will create. Keep your resume' up to date.

[jerry1]

Well, I copied your inputs and emailed
it to her. But she still believes that
she needs permissions to use umask and
that it is preventing the oracle install
from creating it's executable files.
She thinks I am holding back from her the
solution to her problem.

Just can't win. My peer admin can't believe
anyone could be so dense.

[Gary L. Paveza, Jr.]

Jerry,

My sympathies. Our DBAs began by insisting on root privs. Fortunately, management agreed they don't need it. The only time this becomes an issue (small) is when they do an upgrade. Root is needed to run one small script.

Bill,

Root does have full DB access. Just make it a member of the dba group and voila. Access as system manager :)

[A. Clay Stephenson]

Okay, here is my last (and hopefully definitive) method to prove to your dba that you are not holding out on her. The best that I can suggest is a small C program (attached). It's intentionally done in K&R C so that it will compile with even the Bundled compiler.

compile it like this:
cc ftest.c -o ftest777

Then execute it and it will create 'myfile' with 777 mode (subject to the effects of your current umask setting). Myfile is a one-liner that does an ls -l /etc and you should be able to execute it.

Now, I want you to alter the source file and change the 3rd argument of the open() system call from 0777 to 0666 and compile again.

cc ftest.c -o ftest666.

rm myfile and execute ftest666. This time myfile will have a mode of 666 (again, subject to the effects of your current umask).

Momma says "umask is as umask does.". Umask can't put back what was not there (the creation mode) in the first place. Similarly there is a difference between ignorance and stupidity; one can be treated the other can't.

I would never allow a dba to have root access. At most, you should setup sudo to perform task that they can clearly define.
Sooner or later, you are going to have "unused" disks clobbered or the kernel tuned "much better" --- and the bad news is that whatever happens it's your fault. In an effort to level the playing field, ask the dba to give you the privileged database user's passwords so that you can "fix" database problems. You don't need them and she doesn't need to be root.

[jerry1]

Clay, you are the man!

Thanks.