Bug 139475 - Scripts doesn't respect umask
Scripts doesn't respect umask
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-16 02:05 EST by Kasper Dupont
Modified: 2014-03-16 22:50 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-16 12:20:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kasper Dupont 2004-11-16 02:05:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
/etc/bashrc is executed in every shell from ~/.bashrc. /etc/bashrc
will always set the umask, even noninteractive shells. This cause any
script using bash as interpreter to change the umask.

Version-Release number of selected component (if applicable):
setup-2.5.33-1

How reproducible:
Always

Steps to Reproduce:
1. Create a script using bash as interpreter which will create a new file.
2. Change the umask
3. Run the script
    

Actual Results:  
[root@marvin tmp]# cat test.sh 
#!/bin/bash
rm -f test
touch test
[root@marvin tmp]# umask 077
[root@marvin tmp]# ./test.sh 
[root@marvin tmp]# ls -l test
-rw-r--r--  1 root root 0 Nov 16 07:45 test
[root@marvin tmp]# 


Expected Results:  
[root@marvin tmp]# ls -l test
-rw-------  1 root root 0 Nov 16 07:45 test
[root@marvin tmp]# 


Additional info:

Suggested solution. Remove the umaks lines from /etc/bashrc and
optionally put them in /etc/profile instead. Besides being in the
wrong location, I also think it is a bad idea to use a umask of 002 in
some cases. This is known to cause problems when a user create .ssh
and sshd refuse to use it because of wrong permissions.
Comment 1 Bill Nottingham 2004-11-16 12:20:22 EST
I don't think changing this behavior after this number of years to be
practical; it's now expected to work this way.

Note You need to log in before you can comment on or make changes to this bug.