Bug 437465 - "dos2unix -n" creates files with overly restrictive permissions
"dos2unix -n" creates files with overly restrictive permissions
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dos2unix (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Tim Waugh
Depends On:
Blocks: 531928
  Show dependency treegraph
Reported: 2008-03-14 08:00 EDT by john.haxby@oracle.com
Modified: 2013-04-15 04:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 531928 (view as bug list)
Last Closed: 2009-02-11 09:28:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed Patch (890 bytes, patch)
2008-03-14 08:00 EDT, john.haxby@oracle.com
no flags Details | Diff

  None (edit)
Description john.haxby@oracle.com 2008-03-14 08:00:11 EDT
Description of problem:

"dos2unix -n" creates its new file with an overly restrictive mode: in fact the
new file is always created with mode 600.  This differs from "dos2unix -a" where
the mode of the file is retained and "cp" which keeps the source file mode,
modulo the umask.

Version-Release number of selected component (if applicable): 3.1-21.2 (also
present in several other versions, including those on RHEL4 and Fedora8)

How reproducible: always

Steps to Reproduce:
1.  touch xxx
2.  dos2unix -n xxx yyy
3.  ls -l xxx yyy
Actual results:

Assuming your umask is 002, xxx has permissions 664 but yyy has permissions 600

Expected results:

yyy should have the same permissions as xxx (modulo the umask)

Additional info:

I would expect similar permissions to those obtained from "cp xxx yyy"   The
attached patch does exactly that: the temporary file created for the conversion
has its permissions change to match the source file with the bits from the
current umask masked off.
Comment 1 john.haxby@oracle.com 2008-03-14 08:00:11 EDT
Created attachment 298043 [details]
Proposed Patch
Comment 2 john.haxby@oracle.com 2008-03-14 08:01:03 EDT
The same patch can be applied to dos2unix from both RHEL4 and Fedora8
Comment 3 Tim Waugh 2008-03-14 08:14:54 EDT
Thanks for the patch.
Comment 4 john.haxby@oracle.com 2008-03-14 09:14:49 EDT
See also 437469
Comment 6 Phil Knirsch 2008-04-30 11:52:09 EDT
Proposing for RHEL-5.3 and granting Devel ACK.

Read ya, Phil
Comment 7 Tim Waugh 2008-05-06 05:04:21 EDT
If bug #437469 is a FasTrack candidate, this bug should be as well.
Comment 8 Phil Knirsch 2008-05-14 10:18:26 EDT
As per comment #7 proposing bug for RHEL-5.3 FasTrack.

Read ya, Phil
Comment 11 RHEL Product and Program Management 2008-06-23 17:08:02 EDT
This bugzilla was reviewed by QE as a non-FasTrack request.
It has since been proposed for FasTrack. The qa_ack has 
been reset. QE needs to re-review this bugzilla for FasTrack.
Comment 17 errata-xmlrpc 2009-02-11 09:28:53 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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