Bug 437465 - "dos2unix -n" creates files with overly restrictive permissions
"dos2unix -n" creates files with overly restrictive permissions
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dos2unix (Show other bugs)
5.1
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)
Environment:
Last Closed: 2009-02-11 09:28:53 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)
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.

http://rhn.redhat.com/errata/RHBA-2009-0276.html

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