This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] New release of setup.exe (188.8.131.52)
On Sat, Mar 15, 2003 at 11:17:53AM +0100, Markus Schönhaber wrote:
> >>>>I just started setup under a non-privileged account and XP's mechanism
> >>>>show the "Run as Administrator" dialog when starting a program called
> >>>>"setup.exe" or "install.exe" kicked in.
> I have done some more research now but it seems the exact specification is
> buried somewhere where at least I can't find it. Nevertheless I have found
> some potential reasons for the "Install Program as other User" dialog not
> appearing. In the W2k Group Policy Reference there are two pages related
> to this:
> describes how to turn off this feature using group policy, while
> explains how to enable it even for network shares.
> There is (as always?) a registry entry related to the Group Policy:
> (should check for Microsoft's documentation regarding this point - but I
> believe him)
> There is also a knowledge base article with the same info:
> Just loosely related but also interesting:
> This clearly doesn't answer your questions where this feature is
> documented and whether it is language dependent but it hints at two more
> spots to look at when it's not working:
> - it might be turned off by Group Policy or the corresponding registry
> - setup.exe might reside on a network share meaning that the "Install..."
> dialog won't show up by default (could verify that behaviour on my machine).
OK, thanks for the research, Markus. That's a feature that looks useful but
it complicates the support. When a user reports a problem with setup we don't
know if it "Ran As", or not. Most users think the pop up is from setup itself,
one of the many questions setup asks, and few ever mention it.
Software that is run my thousands of users, many of them newbies, should act
predictably. Perhaps we should rename setup.exe to something that won't trigger
the Run As, such as cygsetup.exe Sophisticated users can always Run As
> >I recall another problem that somebody had reported after answering "yes".
> >The chown command in a postinstall script had no effect. That would mean
> >that at, at least at that site, the program was lacking the Restore
> >To test if this is a prevalent problem, a simple test is to put a
> >testchown.sh script in /etc/postinstall . setup will then run it and wecan
> >see if the command worked.
> I'll check that out. But you'll have to explain that to me in clear and
> simple words, that even I am able to understand what I am supposed to do.
Very simple. Put the text below in /etc/postinstall/testchown.sh, then run setup
as an ordinary user (with Run As). After running, there should by a file
/etc/testchown, containing info about user & group membership (can be useful).
Check if it is owned by SYSTEM or not. testchown.sh will be renamed to
testchown.sh.done, so you need to undo the renaming if you try multiple times.
Again the purpose of the test is to understand what users face.
rm -f /etc/testchown
id >> /etc/testchown
chown 18:18 /etc/testchown
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html