Bug 437469 - "unix2dos -n" creates files with overly restrictive permissions
"unix2dos -n" creates files with overly restrictive permissions
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: unix2dos (Show other bugs)
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)
Last Closed: 2009-02-18 05:00:58 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 (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
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.


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