From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28959 invoked by alias); 10 Nov 2013 17:56:32 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 28940 invoked by uid 89); 10 Nov 2013 17:56:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.2 X-HELO: mho-02-ewr.mailhop.org Received: from Unknown (HELO mho-02-ewr.mailhop.org) (204.13.248.72) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 10 Nov 2013 17:56:30 +0000 Received: from pool-98-110-183-69.bstnma.fios.verizon.net ([98.110.183.69] helo=cgf.cx) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1VfZFG-000Ia4-M6 for cygwin-apps@cygwin.com; Sun, 10 Nov 2013 17:56:22 +0000 Received: from cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 365FB60120 for ; Sun, 10 Nov 2013 12:56:20 -0500 (EST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/PASOfj8yCH6Y2I/LQEtcx Date: Sun, 10 Nov 2013 17:56:00 -0000 From: Christopher Faylor To: cygwin-apps@cygwin.com Subject: Re: [GOLDSTAR] Re: [PATCH] setup: allow running as non-admin Message-ID: <20131110175620.GA7752@ednor.casa.cgf.cx> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <527AE157.4080107@shaddybaddah.name> <20131107131521.GA5722@calimero.vinschen.de> <20131107152342.GA3974@ednor.casa.cgf.cx> <527D7C12.6090204@shaddybaddah.name> <20131109004042.GA5742@ednor.casa.cgf.cx> <20131109102001.GI16306@calimero.vinschen.de> <6CF2FC1279D0844C9357664DC5A08BA21B2F85@MLBXV06.nih.gov> <20131109173050.GN16306@calimero.vinschen.de> <20131110072828.GB3090@ednor.casa.cgf.cx> <20131110122802.GO16306@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131110122802.GO16306@calimero.vinschen.de> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-11/txt/msg00037.txt.bz2 On Sun, Nov 10, 2013 at 01:28:02PM +0100, Corinna Vinschen wrote: >On Nov 10 02:28, Christopher Faylor wrote: >> On Sat, Nov 09, 2013 at 06:30:50PM +0100, Corinna Vinschen wrote: >> >What changed is the way how normal users can install for "just them". >> >No name tweak but an option instead. Given what you wrote, an >> >installation as normal user right from the net was not possible before, >> >so just the method to do it changed slightly. By documenting it >> >somewhere, we should be all set, shouldn't we? >> >> So, in other words, an end user will no longer have to rename setup*.exe >> to foo.exe to bypass enforced elevation but will, instead, just have to >> use a command-line option. Sounds good to me. We can add words for >> that to the install.html web page and to the FAQ. > >Exactly what I had in mind. I have some changes to setup-net.xml in the >loop. I'll add some more to the FAQ and upload that next week. > >Nevertheless, on second thought we *could* do more, if we want to, >now that we have our permissions completely under our own control. > >Provided somebody has fun working on that stuff, what we could do, >for instance: > >- Per the Microsoft UAC guidelines(*) the elevation prompt should not > be shown at all if UAC is switched off. The idea is to show a dialog > instead, telling the user "this application requires admin privs, > yada yada", but in fact our setup would run as normal user just fine > if we let it. See the next point. > >- Right now setup simply exits if the elevation didn't work or was > canceled. What about a dialog instead, which asks the user something > along the lines of "Elevation canceled" or "UAC turned off", and then > "Setup can run without admin privs with some restrictions, are you > aware of them and do you want to do that? [Yes/No]" > >- This could be even more elegant if setup checks if the installer path > in the registry is in HKLM. If so, it could refuse to do its stuff > without admin rights, because it knows that the original installation > has been performed with admin rights. Chances are high then, that a > normal user won't have enough permissions to update the installation. > >- Something we could have done all along (and which has been mentioned > on the Cygwin ML): We could drop the "All users"/"Just me" choice if > the user has no admin rights. After all, the "All user" stuff can't > be written anyway without admin rights. All good SHTDI ideas. cgf