Bug 34295 - dangerous umask
dangerous umask
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
7.1
i386 Linux
high Severity high
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-01 13:15 EDT by Andreas J. Bathe
Modified: 2014-03-16 22:20 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-04 01:58:56 EDT
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 Andreas J. Bathe 2001-04-01 13:15:03 EDT
initscripts-5.78-1:

when seeing /etc/issue and /etc/issue.net with -rw-rw-rw- privileges I
found that the umask is set to 0 when the script rc.local is executed. I
mean that is a very dangerous umask. Everything created within the startup
scripts will be privileded with 666. Have a look within /var what a bunch
of files will have -rw-rw-rw-. Not very secure...

Take care
Andreas
Comment 1 Bill Nottingham 2001-04-01 23:05:09 EDT
I can't reproduce this here. /etc/issue* has 644 permissions.
Comment 2 Andreas J. Bathe 2001-04-03 12:04:24 EDT
It look's like a kernel issue: Please reproduce with the stock 2.4.3 kernel and
see what the umask within rc.local ist. Here I got good umask with the rawhide
kernel 2.4.2-0.1.28 and the bad one when exchanging it with the vanilla 2.4.3
kernel.

Take care
Andreas
Comment 3 Bill Nottingham 2001-04-04 01:56:35 EDT
Hm, this should probably actually be patched in init.
Comment 4 Bill Nottingham 2001-04-04 01:57:40 EDT
someone should try and reproduce this inhouse.
Comment 5 Bill Nottingham 2001-04-04 01:58:49 EDT
(Disregard that last comment. Too many windows open.)
Comment 6 Bill Nottingham 2001-08-07 03:00:19 EDT
This was patched into the init that shipped with 7.1.

AFAIK, the kernel change has been reverted since then anyway.

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