Bug 139475 - Scripts doesn't respect umask
Summary: Scripts doesn't respect umask
Alias: None
Product: Fedora
Classification: Fedora
Component: setup   
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-16 07:05 UTC by Kasper Dupont
Modified: 2014-03-17 02:50 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Kasper Dupont 2004-11-16 07:05:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

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):

How reproducible:

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 
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 17:20:22 UTC
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.