Bug 139475 - Scripts doesn't respect umask
Summary: Scripts doesn't respect umask
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: setup
Version: 2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2004-11-16 17:20:22 UTC
Type: ---
Embargoed:


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