Bash 'umask' builtin doesn't set 'x' permissions?

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Jim Fische » Sun, 13 Jul 2003 04:58:15



I was tinkering around with the Bash builtin command 'umask' (on a Red
Hat Linux 9 box) and noticed the following behavior:

    [bash]$ rm -f ./try; umask 0002; touch try; ls -l try
    -rw-rw-r--    1 me       me              0 Jul 11 14:49 try
    [bash]$ umask -S
    u=rwx,g=rwx,o=rx

Note that the 'x' bits are not turned on for the newly created file
'try'. IOW, I expected try's file permissions would be set to
"-rwxrwxr-x". Why weren't they? Is this a "Bash thing" or a "Red Hat
thing" or other?

--
Jim

To reply by email, remove "link" and change "now.here" to "yahoo"
jfischer_link5809{at}now.here.com

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Dan Merce » Sun, 13 Jul 2003 05:05:34


: I was tinkering around with the Bash builtin command 'umask' (on a Red
: Hat Linux 9 box) and noticed the following behavior:
:
:     [bash]$ rm -f ./try; umask 0002; touch try; ls -l try
:     -rw-rw-r--    1 me       me              0 Jul 11 14:49 try
:     [bash]$ umask -S
:     u=rwx,g=rwx,o=rx
:
: Note that the 'x' bits are not turned on for the newly created file
: 'try'. IOW, I expected try's file permissions would be set to
: "-rwxrwxr-x". Why weren't they? Is this a "Bash thing" or a "Red Hat
: thing" or other?
:

Umask only masks off bits.  Execute bits must be set explicitly - as they will be
by mkdir and ld.  Would you really want random files created with their
execute bits set?

Dan Mercer

: --
: Jim
:
: To reply by email, remove "link" and change "now.here" to "yahoo"
: jfischer_link5809{at}now.here.com
:
:

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Kevin Rodger » Sun, 13 Jul 2003 05:44:03



> Umask only masks off bits.  Execute bits must be set explicitly - as they will be
> by mkdir and ld.  Would you really want random files created with their
> execute bits set?

Not generally, but I can imagine cases where I might.

--
Kevin Rodgers

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Barry Margoli » Sun, 13 Jul 2003 05:06:59




Quote:>I was tinkering around with the Bash builtin command 'umask' (on a Red
>Hat Linux 9 box) and noticed the following behavior:

>    [bash]$ rm -f ./try; umask 0002; touch try; ls -l try
>    -rw-rw-r--    1 me       me              0 Jul 11 14:49 try
>    [bash]$ umask -S
>    u=rwx,g=rwx,o=rx

>Note that the 'x' bits are not turned on for the newly created file
>'try'. IOW, I expected try's file permissions would be set to
>"-rwxrwxr-x". Why weren't they? Is this a "Bash thing" or a "Red Hat
>thing" or other?

This is a standard Unix thing.  Umask doesn't turn on permissions, it only
turns *off* permissions.  The application that creates the file specifies
the maximum permissions, and then the bits specified in umask turn some of
them off.  Most applications specify 666 as the maximum; when you apply the
002 umask to that, you get 664, which is rw-rw-r--.

The only applications that normally specify 777 as the maximum permissions
are programs that create directories (e.g. mkdir) or executable files
(compilers and linkers).

--

Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Barry Margoli » Sun, 13 Jul 2003 06:01:25





>> Umask only masks off bits.  Execute bits must be set explicitly - as
>they will be
>> by mkdir and ld.  Would you really want random files created with their
>> execute bits set?

>Not generally, but I can imagine cases where I might.

But how is the system supposed to know a priori when it's such a case?  The
default permissions that applications use handle the normal case, which is
that tools like text editors and shell redirection create text data files,
which don't need execute permissions

On the occasions where you're creating scripts, how difficult is it to do a
chmod after?

--

Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Jim Fische » Sun, 13 Jul 2003 06:47:33





>>I was tinkering around with the Bash builtin command 'umask' (on a Red
>>Hat Linux 9 box) and noticed the following behavior:

>>   [bash]$ rm -f ./try; umask 0002; touch try; ls -l try
>>   -rw-rw-r--    1 me       me              0 Jul 11 14:49 try
>>   [bash]$ umask -S
>>   u=rwx,g=rwx,o=rx

>>Note that the 'x' bits are not turned on for the newly created file
>>'try'. IOW, I expected try's file permissions would be set to
>>"-rwxrwxr-x". Why weren't they? Is this a "Bash thing" or a "Red Hat
>>thing" or other?

> This is a standard Unix thing.  Umask doesn't turn on permissions, it only
> turns *off* permissions.  The application that creates the file specifies
> the maximum permissions, and then the bits specified in umask turn some of
> them off.  Most applications specify 666 as the maximum; when you apply the
> 002 umask to that, you get 664, which is rw-rw-r--.

Ah, that's right. The permission bits specified by the create() and
open() system calls are bit-wise ANDed with the complement of the umask
value to obtain the actual permission bits:

    actual_mode = create_mode & ~umask

And by convention, the default file permission bits are specified as "0666".

Dang. I forgot all about this stuff for a moment there. I must be having
a caffeine craving, or a dreaded "senior moment", or something. ;-)
Anyway, thanks for all the replies.

--
Jim

To reply by email, remove "link" and change "now.here" to "yahoo"
jfischer_link5809{at}now.here.com

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Kevin Rodger » Wed, 16 Jul 2003 01:08:00






>>>Umask only masks off bits.  Execute bits must be set explicitly - as
>>>they will be
>>>by mkdir and ld.  Would you really want random files created with their
>>>execute bits set?

>>Not generally, but I can imagine cases where I might.

> But how is the system supposed to know a priori when it's such a case?  The
> default permissions that applications use handle the normal case, which is
> that tools like text editors and shell redirection create text data files,
> which don't need execute permissions

I don't expect the system to know.  I'm just curious why the execute bits
are treated differently than the read and write bits.  It seems like it'd
be simpler to treat them the same in the system call, but turn them via the
default umask.

Quote:> On the occasions where you're creating scripts, how difficult is it to do a
> chmod after?

Not hard, but if I'm generating 10,000 scripts at a time, that's 10,000 calls

to an external utility.

--
Kevin Rodgers

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Barry Margoli » Wed, 16 Jul 2003 02:40:47





>> But how is the system supposed to know a priori when it's such a case?  The
>> default permissions that applications use handle the normal case, which is
>> that tools like text editors and shell redirection create text data files,
>> which don't need execute permissions

>I don't expect the system to know.  I'm just curious why the execute bits
>are treated differently than the read and write bits.  It seems like it'd
>be simpler to treat them the same in the system call, but turn them via the
>default umask.

Because a typical umask will usually give execute permission to anyone with
read permissions.  And the end result will be that *every* file you created
would have execute permissions, even if it's not something that should be
executed.

And if you mask off the execute bit in your umask, then commands like ld
and mkdir will end up creating files/directories that are missing their
execute permissions, even though it's normal for these types of objects to
be executable.

The problem is that umask is normally something the user sets once at login
time, not something they adjust before each command to ensure that it
creates files with the expected permissions.  It's considered to be a
per-user setting, so it needs to be appropriate for most situations.  To
account for this, applications specify maximum permissions appropriate for
the types of files they normally create.  And in order not to create lots
of data files with execute permissions, programs that normally create data
files don't include the execute bit.

Quote:>> On the occasions where you're creating scripts, how difficult is it to do a
>> chmod after?

>Not hard, but if I'm generating 10,000 scripts at a time, that's 10,000 calls
>to an external utility.

How many calls are you making to generate each of those scripts, and what's
one more call on top of that?

--

Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

Bash 'umask' builtin doesn't set 'x' permissions?

Post by Villy Kru » Wed, 16 Jul 2003 17:09:22


On Mon, 14 Jul 2003 10:08:00 -0600,

Quote:

>I don't expect the system to know.  I'm just curious why the execute bits
>are treated differently than the read and write bits.  It seems like it'd
>be simpler to treat them the same in the system call, but turn them via the
>default umask.

It does.  However, the creat() -- or open() with O_CREAT -- needs to
request the execute bit to be set, and the umask will then remove the
unwanted permission bits according to the mask value.  When compiling
a program the executable file will be created using creat() with mode
value of 0777.  When creating a text file using your text editor the
mode value specified in the creat() call is 0666.  This makes sense as
the vast majority of text file should not have execute permissions set.

Villy

 
 
 

1. ping -g 'gateway-IP' 'host-IP' DOESN'T work!

Hello guys,

I have a machine with two interfaces, each connected to
a gateway. This two gateways are then connected to a common
network and I want to ping another router in that network over
the two interfaces.

Looks like this:
                        Gateway 1
                           ----
               ------------|  |------------
              | Subnet A   ----            |
            ----
Machine    |  |                Subnet C   Router
            ----
              | Subnet B   ----            |
               ------------|  |------------
                           ----
                        Gateway 2

Now if I type following on my machine it doesn't work:

ping -g 'IP in Subnet A of Gateway 1' 'Router-IP-address'

But if I do a ping (Defaultgateway is 'IP in Subnet A of Gateway 1'
(without -g) it works fine:

ping 'Router-IP-address'

Can someone give me a hint? Thanks in advance!

Cheers, Walter

2. Solaris 10 NFS

3. 'ping' sees route but 'telnet' doesn't??

4. Telnet macro. Does it exist?

5. cvsup doesn't like tags 'ports-all' & 'doc-all'

6. hdb: no reponse (status 0xd0) on ide cdrom

7. 'ppp-on' Works, 'ifup ppp0' Doesn't

8. DNS DUH!

9. Why: perl -e <<'EOF' doesn't work (bash)

10. Rdump say 'permission denied' rsh doesn't, why?

11. Any way to disable path expansion while using the 'read' builtin in bash ?

12. (patch for Bash) 'arraymap', 'arrayfilter' builtins

13. why can't I set 'rw' permissions to my msdos partition?