This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [1.7] rebaseall doesn't solve the problem
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 1 Mar 2009 11:20:35 +0100
- Subject: Re: [1.7] rebaseall doesn't solve the problem
- References: <499F6682.1090204@cwilson.fastmail.fm> <20090224100616.GC6035@calimero.vinschen.de> <49A85971.6070300@cwilson.fastmail.fm> <20090228104337.GG19887@calimero.vinschen.de> <49A986B4.2080501@cwilson.fastmail.fm> <20090228201625.GA8503@calimero.vinschen.de> <49A9AA0C.9020904@cwilson.fastmail.fm>
- Reply-to: cygwin at cygwin dot com
On Feb 28 16:18, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > Uh, ok. In that case, yes, it needs some tweaking. Actually, maybe
> > the tool should really be named differently. Something suggesting
> > that it in general changes Win32-related PE/COFF header flags. ASLR
> > and TS-aware are just some of them, in theory.
>
> I'm open to suggestions. "peimgflags"? Currently, aslr only
peflags?
> > I have to test if the TS-aware flag makes any difference on
> > a 2K8 TS machine anyway. I think (and hope) that this flag will
> > persuade tsappcmp.dll into igoring an executable instead of scrambling
> > its page executable protection flags. If so, we should really set this
> > flag in all applications. Well, not that I gave up the idea that
> > Microsoft should fix that bug in tsappcmp.dll in the first place...
>
> Ha!
Can you tweak the tool so I can test that next week?
> Or a separate aslrall (peimgflags(?)_all) script...it would share a lot
> of code with rebaseall, but it's not really all THAT big a script. The
> reason I didn't do that originally was I wanted to reuse the same
> (generated) filelist in each case. But, it seems that the flexibility
> in having aslrall(?) make its own file list -- which may include exe's
> as well as dll's -- is more important.
+1
> >> That would be nice. However, ONLY exe's linked with cygwin1.dll should
> >> be marked this way, right? Not cygcheck, strace, and whatever other few
> >> exes we might find in the cygwin installation lists.
> >
> > Hmm, I'm not sure about that one. At least only EXEs should be marked
> > TS-aware automatically. The flag has no meaning on DLLs, afaik.
> > *Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big
> > help in all cases. Cygwin applications are TS-aware by default anyway.
> > If somebody actually manages to write a non-TS-aware Cygwin application,
> > I'd say this guy should reset the TS-aware flag manually.
Something I forgot in my other reply from a few minutes ago:
Cygwin applications are POSIX applications which are by default
multiuser aware == TS-aware since they are written for such an
environment. Should an application *prove* to make trouble in a
TS-environment (minus the tsappcmp.dll bug) then we should try to find
out why. In that case, especially if it's a plain POSIX tool, it might
be a bug in Cygwin itself. Other than that, Cygwin and Cygwin apps are
designed to interact cleanly in a multiuser environment. It should not
matter under which account they are running, even SYSTEM.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/