Closed Bug 287315 Opened 20 years ago Closed 20 years ago

do not use cp to install ua.css

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: timeless, Assigned: timeless)

Details

Attachments

(1 obsolete file)

this is a transcript of the brain damage derived from cygwin cp and should be sufficient reason for us *never* to use it in makefiles. R:\mozilla\all-i686-pc-cygwin\dist\bin>cacls ..\..\..\layout\style\quirk.css R:\mozilla\layout\style\quirk.css BUILTIN\Administrators:F NT AUTHORITY\SYSTEM:F CTS\time:F BUILTIN\Users:R R:\mozilla\all-i686-pc-cygwin\dist\bin>where cp.exe r:\cygwin\bin\cp.exe R:\mozilla\all-i686-pc-cygwin\dist\bin>cp ../../../layout/style/quirk.css . R:\mozilla\all-i686-pc-cygwin\dist\bin>cacls quirk.css R:\mozilla\all-i686-pc-cygwin\dist\bin\quirk.css CTS\time:(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES CTS\Domain Users:(special access:) READ_CONTROL FILE_READ_EA FILE_READ_ATTRIBUTES Everyone:(special access:) READ_CONTROL FILE_READ_EA FILE_READ_ATTRIBUTES -- So, what's wrong with this picture? well... running as local user "test" which is a member of everyone: R:\mozilla\all-i686-pc-cygwin\dist\bin>type "R:\mozilla\all-i686-pc-cygwin\dist\bin\res\ua.css" Access is denied. Mozilla apps suffer from the same fate. (yes, the example used quirk.css, but that's just an example, the real makefile uses ua.css.) for comparison: R:\mozilla\all-i686-pc-cygwin\dist\bin>del quirk.css R:\mozilla\all-i686-pc-cygwin\dist\bin>nsinstall ../../../layout/style/quirk.css . R:\mozilla\all-i686-pc-cygwin\dist\bin>cacls quirk.css R:\mozilla\all-i686-pc-cygwin\dist\bin\quirk.css BUILTIN\Administrators:F NT AUTHORITY\SYSTEM:F CTS\time:F BUILTIN\Users:R
Attached patch use nsinstall (obsolete) — Splinter Review
Attachment #178331 - Flags: superreview?(bzbarsky)
Attachment #178331 - Flags: review?(bzbarsky)
Comment on attachment 178331 [details] [diff] [review] use nsinstall r+sr=bzbarsky, though we really need to go back to just symlinking this... :(
Attachment #178331 - Flags: superreview?(bzbarsky)
Attachment #178331 - Flags: superreview+
Attachment #178331 - Flags: review?(bzbarsky)
Attachment #178331 - Flags: review+
> r+sr=bzbarsky, though we really need to go back to just symlinking this... :( doesn't nsinstall symlink on platforms where it is supported?
...which leads to the question: how does this differ from bug 266930, which was backed out (for srcdir tainting)?
i think the answer is that the install target uses INSTALL which in config.mk tends to pass -L or -R to nsinstall.
Status: NEW → ASSIGNED
So to be clear, the review was conditional on the file always being copied... If it's not, I withdraw the review (for reasons mentioned in bug 266930).
Comment on attachment 178331 [details] [diff] [review] use nsinstall mozilla/layout/style/Makefile.in 1.5
Attachment #178331 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Just to complete the picture, it is not just cp that does this lame stuff. All Cygwin tools are liable to totally butcher NTFS permissions, due to the NtSec module in Cygwin, which should never have been enabled IMHO. Adding the token 'NONTSEC' to the CYGWIN env var stops it doing anything, though.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: