Bug 437469 - "unix2dos -n" creates files with overly restrictive permissions
"unix2dos -n" creates files with overly restrictive permissions
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: unix2dos (Show other bugs)
5.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks: 531926
  Show dependency treegraph
 
Reported: 2008-03-14 09:13 EDT by john.haxby@oracle.com
Modified: 2013-04-15 04:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 531926 (view as bug list)
Environment:
Last Closed: 2009-02-18 05:00:58 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 (915 bytes, patch)
2008-03-14 09:13 EDT, john.haxby@oracle.com
no flags Details | Diff

  None (edit)
Description john.haxby@oracle.com 2008-03-14 09:13:01 EDT
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 09:13:01 EDT
Created attachment 298044 [details]
Proposed Patch
Comment 2 john.haxby@oracle.com 2008-03-14 09:14:14 EDT
The same patch can be applied to both RHEL4 and Fedora8
Comment 3 Tim Waugh 2008-03-14 09:23:55 EDT
Thanks.
Comment 5 Phil Knirsch 2008-04-30 12:02:08 EDT
Simple fix. Proposing for RHEL-5.3 FasTrack and granting Devel ACK.

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

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