Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 437469

Summary: "unix2dos -n" creates files with overly restrictive permissions
Product: Red Hat Enterprise Linux 5 Reporter: john.haxby <john.haxby>
Component: unix2dosAssignee: Tim Waugh <twaugh>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 5.1CC: psplicha, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 531926 (view as bug list) Environment:
Last Closed: 2009-02-18 10:00:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 531926    
Attachments:
Description Flags
Proposed Patch none

Description john.haxby@oracle.com 2008-03-14 13:13:01 UTC 
Description of problem:

"unix2dos -n" creates its new file with an overly restrictive mode: in fact the
new file is always created with mode 600.  This differs from "unix2dos -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): 2.2-26.2.2 (also
present in several other versions, including those on RHEL4 and Fedora8)


How reproducible: always




Steps to Reproduce:
1.  touch xxx
2.  unix2dos -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.

See also bug 437465
Comment 1 john.haxby@oracle.com 2008-03-14 13:13:01 UTC 
Created attachment 298044 [details]
Proposed Patch
Comment 2 john.haxby@oracle.com 2008-03-14 13:14:14 UTC 
The same patch can be applied to both RHEL4 and Fedora8
Comment 3 Tim Waugh 2008-03-14 13:23:55 UTC 
Thanks.
Comment 5 Phil Knirsch 2008-04-30 16:02:08 UTC 
Simple fix. Proposing for RHEL-5.3 FasTrack and granting Devel ACK.

Read ya, Phil
Comment 7 Tim Waugh 2008-05-06 09:04:19 UTC 
If this bug is a FasTrack candidate, bug #437465 should be as well.
Comment 9 RHEL Program Management 2008-06-23 21:07:58 UTC 
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 14 errata-xmlrpc 2009-02-18 10:00:58 UTC 
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-0294.html