* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) [not found] ` <6CF2FC1279D0844C9357664DC5A08BA215F9C7@MLBXV06.nih.gov> @ 2013-10-15 9:08 ` Corinna Vinschen 2013-10-15 10:21 ` Shaddy Baddah 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2013-10-15 9:08 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 2144 bytes --] [Redirected to cygwin-apps] On Sep 23 13:57, Buchbinder, Barry (NIH/NIAID) [E] wrote: > Larry Hall (Cygwin) sent the following at Sunday, September 22, 2013 9:42 PM > >No, "All Users" is also required to set up services (like sshd, crond, > >etc.) to work for all users (i.e. switch user context). This is the > >recommended way to install so that these subsequent facilities can be > >used with a minimum of fuss or trouble. > > Thank you for the explanation. > > Still, I'd like to urge the setup-meisters to keep those of us without > admin rights in mind. If we have to compile setup ourselves, many of > us will be staying with 32 bit for a long time. I just had a weird idea how we *might* accomplish this for 32 and 64 bit in the same way. Assuming setup would get an "asInvoker" manifest, so it runs with the privileges of the current user. First thing it would check its user token. There are three cases: - When started by a non-admin user, the user token would contain no trace of the administrators group in the user token group list. In this case, setup would just run along as usual for the current user. - When started elevated (with "Run as administrator...", for instance), the user token group list would contain the administrators group, enabled. So setup knows it has admin rights anyway and just runs along as in the non-admin user case. So, in fact, these two cases are just one case. - Now, when started by an admin user, but not elevated, the group list would contain the administrators group, too, but with the "Use for deny only" flag set. If setup recognizes this flag, rather than running along, it calls ShellExecute on itself, with the "runas" flag set. So it elevates a copy of itself and just exits. The elevated copy then runs as usual. The only downside with this concept, as far as I can see, is, somebody would have to implement it... Does that sound feasible? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-10-15 9:08 ` cannot run setup64.exe without admin privileges (even if renamed foo.exe) Corinna Vinschen @ 2013-10-15 10:21 ` Shaddy Baddah 2013-10-15 12:22 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Shaddy Baddah @ 2013-10-15 10:21 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 2417 bytes --] Hi Corinna, On 15/10/13 20:08, Corinna Vinschen wrote: > [Redirected to cygwin-apps] > > > On Sep 23 13:57, Buchbinder, Barry (NIH/NIAID) [E] wrote: >> Larry Hall (Cygwin) sent the following at Sunday, September 22, 2013 9:42 PM >>> No, "All Users" is also required to set up services (like sshd, crond, >>> etc.) to work for all users (i.e. switch user context). This is the >>> recommended way to install so that these subsequent facilities can be >>> used with a minimum of fuss or trouble. >> >> Thank you for the explanation. >> >> Still, I'd like to urge the setup-meisters to keep those of us without >> admin rights in mind. If we have to compile setup ourselves, many of >> us will be staying with 32 bit for a long time. > > I just had a weird idea how we *might* accomplish this for 32 and 64 bit > in the same way. > > Assuming setup would get an "asInvoker" manifest, so it runs with the > privileges of the current user. First thing it would check its user > token. There are three cases: > > - When started by a non-admin user, the user token would contain no > trace of the administrators group in the user token group list. > In this case, setup would just run along as usual for the current user. > > - When started elevated (with "Run as administrator...", for instance), > the user token group list would contain the administrators group, > enabled. So setup knows it has admin rights anyway and just runs along > as in the non-admin user case. So, in fact, these two cases are just > one case. > > - Now, when started by an admin user, but not elevated, the group list > would contain the administrators group, too, but with the "Use for > deny only" flag set. If setup recognizes this flag, rather than running > along, it calls ShellExecute on itself, with the "runas" flag set. > So it elevates a copy of itself and just exits. The elevated copy > then runs as usual. > > The only downside with this concept, as far as I can see, is, somebody > would have to implement it... > > Does that sound feasible? I apologise... I've been sitting on an almost-there implementation of this for almost two weeks, waiting for a moment to polish it properly for patch submission. I can't elaborate on the pros and cons of the patch at the moment, as I am accessing my desktop remotely. But I will follow-up later tonight with more details. -- Regards, Shaddy [-- Attachment #2: setup-sans-admin.patch.gz --] [-- Type: application/x-gzip, Size: 3292 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-10-15 10:21 ` Shaddy Baddah @ 2013-10-15 12:22 ` Corinna Vinschen 2013-10-15 15:18 ` Shaddy Baddah 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2013-10-15 12:22 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 2501 bytes --] Hi Shaddy, On Oct 15 21:21, Shaddy Baddah wrote: > Hi Corinna, > > On 15/10/13 20:08, Corinna Vinschen wrote: > >[...] > >Assuming setup would get an "asInvoker" manifest, so it runs with the > >privileges of the current user. First thing it would check its user > >token. There are three cases: > > > >- When started by a non-admin user, the user token would contain no > > trace of the administrators group in the user token group list. > > In this case, setup would just run along as usual for the current user. > > > >- When started elevated (with "Run as administrator...", for instance), > > the user token group list would contain the administrators group, > > enabled. So setup knows it has admin rights anyway and just runs along > > as in the non-admin user case. So, in fact, these two cases are just > > one case. > > > >- Now, when started by an admin user, but not elevated, the group list > > would contain the administrators group, too, but with the "Use for > > deny only" flag set. If setup recognizes this flag, rather than running > > along, it calls ShellExecute on itself, with the "runas" flag set. > > So it elevates a copy of itself and just exits. The elevated copy > > then runs as usual. > > > >The only downside with this concept, as far as I can see, is, somebody > >would have to implement it... > > > >Does that sound feasible? > > I apologise... I've been sitting on an almost-there implementation of > this for almost two weeks, waiting for a moment to polish it properly > for patch submission. > > I can't elaborate on the pros and cons of the patch at the moment, as > I am accessing my desktop remotely. But I will follow-up later tonight > with more details. thanks for letting us know and your patch. I had a look and it looks good for a start. You just call the CheckTokenMembership function, though. The problem is, you won't know if the process has been started by a non-admin or by an admin without elevation. So you always call ShellExecute if setup is started without admin rights, for non-admins and non-elevated admins alike, unless the --no-admin option is given. Is that what we want? Or should the process only be elevated when started by a non-elevated admin as I proposed. I'm not sure, really. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-10-15 12:22 ` Corinna Vinschen @ 2013-10-15 15:18 ` Shaddy Baddah 2013-10-15 16:00 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Shaddy Baddah @ 2013-10-15 15:18 UTC (permalink / raw) To: cygwin-apps Hi Corinna, On 15/10/13 23:22, Corinna Vinschen wrote: > Hi Shaddy, > > On Oct 15 21:21, Shaddy Baddah wrote: >> Hi Corinna, >> >> On 15/10/13 20:08, Corinna Vinschen wrote: >>> [...] >>> Assuming setup would get an "asInvoker" manifest, so it runs with the >>> privileges of the current user. First thing it would check its user >>> token. There are three cases: >>> >>> - When started by a non-admin user, the user token would contain no >>> trace of the administrators group in the user token group list. >>> In this case, setup would just run along as usual for the current user. >>> >>> - When started elevated (with "Run as administrator...", for instance), >>> the user token group list would contain the administrators group, >>> enabled. So setup knows it has admin rights anyway and just runs along >>> as in the non-admin user case. So, in fact, these two cases are just >>> one case. >>> >>> - Now, when started by an admin user, but not elevated, the group list >>> would contain the administrators group, too, but with the "Use for >>> deny only" flag set. If setup recognizes this flag, rather than running >>> along, it calls ShellExecute on itself, with the "runas" flag set. >>> So it elevates a copy of itself and just exits. The elevated copy >>> then runs as usual. >>> >>> The only downside with this concept, as far as I can see, is, somebody >>> would have to implement it... >>> >>> Does that sound feasible? >> >> I apologise... I've been sitting on an almost-there implementation of >> this for almost two weeks, waiting for a moment to polish it properly >> for patch submission. >> >> I can't elaborate on the pros and cons of the patch at the moment, as >> I am accessing my desktop remotely. But I will follow-up later tonight >> with more details. > > thanks for letting us know and your patch. I had a look and it looks > good for a start. You just call the CheckTokenMembership function, > though. The problem is, you won't know if the process has been started > by a non-admin or by an admin without elevation. So you always call > ShellExecute if setup is started without admin rights, for non-admins > and non-elevated admins alike, unless the --no-admin option is given. Yes that is deliberate. Initially I coded this for how I viewed was desirable, that being that it would use CheckTokenMembership to see if it was elevated (or just run as Administrator on XP). If it was not, it would attempt to elevate using "runas" flag. If that was rejected, it would carry on. The --no-admin was still used as per the patch submitted to avoid infinite loop just in-case ShellExecuteEx didn't honour "runas" and just ran setup all over again with no Administrator rights. However I sensed from previous discussions that really it was desirable to steer users towards running as Admin/elevated privilege. Unless they really knew what they were doing. So much so that building a custom setup.exe was being recommended without much discussion of an alternative... until now. So this patch tries to be as backwards compatible as possible. That is, unless the user has already explicitly elevated privilege (context menu -> Run as ...), setup.exe forces an attempt. And fails if it does not elevate. The forced attempt can be avoided by explicitly specifying --no-admin. The patch I provided doesn't match exactly the behaviour of setup on various systems at the moment, in the following ways: * I don't know how, and did not bother too much about emulating the "access denied" when the user rejects the privilege elevation. * Under x86 (32bit), where the user has performed the rename magic that normally circumvents the UAC Installer Detection Technology, setup will still behave as if they hadn't and continue to try to elevate. IMO this is minor, but if we were going for 100% compatibility, we could check the exe filename against the same list that cygports uses, and avoid the privilege elevation attempt: /usr/share/cygport/lib/src_postinst.cygpart:1112: find * -type f -executable -a \( -name '*instal*.exe' -o -name '*patch*.exe' -o -name '*setup*.exe' -o -name '*update*.exe' \) -print0 | \ * Under XP (32 bit... I don't know about any other archs (if they exist?) or other XP like editions (server???)), for a non-Administrator the attempt to elevate privilege is also an extra behaviour that wouldn't have been normally encountered. Again, it may have been easy to detect that and do something about it too. Another bit of polish this patch needs is a effective way to close off logging once and for all when we are about to call ShellExecuteEx. Putting in the line: + l->msg.clear(); staved off the doubling up of logging when LogFile::exit was being called. But unfortunately a bunch of newlines where being logged instead. I never got around to knocking all that on the head. > Is that what we want? Or should the process only be elevated when > started by a non-elevated admin as I proposed. I'm not sure, really. If I understand right, you were proposing that if the user was not an Admin at all, then just let them run as they were. As I wrote earlier, it seemed from discussion that it was desirable (if not pseudo policy) that regular Cygwin users run with privilege elevated. And knowing of various features built into setup that require elevated privilege, eg. replace on boot, I can see why that is. But I am happy to be guided either way. I can help out too, but as you can see by the latency in my communication/implementation, I am not a pillar of reliability :-( -- Regards, Shaddy ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-10-15 15:18 ` Shaddy Baddah @ 2013-10-15 16:00 ` Corinna Vinschen 2013-11-04 11:59 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2013-10-15 16:00 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 5507 bytes --] On Oct 16 02:18, Shaddy Baddah wrote: > On 15/10/13 23:22, Corinna Vinschen wrote: > >On Oct 15 21:21, Shaddy Baddah wrote: > >>On 15/10/13 20:08, Corinna Vinschen wrote: > >>>[...] > >thanks for letting us know and your patch. I had a look and it looks > >good for a start. You just call the CheckTokenMembership function, > >though. The problem is, you won't know if the process has been started > >by a non-admin or by an admin without elevation. So you always call > >ShellExecute if setup is started without admin rights, for non-admins > >and non-elevated admins alike, unless the --no-admin option is given. > > Yes that is deliberate. Initially I coded this for how I viewed was > desirable, that being that it would use CheckTokenMembership to see if > it was elevated (or just run as Administrator on XP). If it was not, it > would attempt to elevate using "runas" flag. If that was rejected, it > would carry on. The --no-admin was still used as per the patch > submitted to avoid infinite loop just in-case ShellExecuteEx didn't > honour "runas" and just ran setup all over again with no Administrator > rights. > > However I sensed from previous discussions that really it was desirable > to steer users towards running as Admin/elevated privilege. Unless they > really knew what they were doing. So much so that building a custom > setup.exe was being recommended without much discussion of an > alternative... until now. > > So this patch tries to be as backwards compatible as possible. That is, > unless the user has already explicitly elevated privilege (context > menu -> Run as ...), setup.exe forces an attempt. And fails if it does > not elevate. The forced attempt can be avoided by explicitly specifying > --no-admin. Yeah, that makes sense. > The patch I provided doesn't match exactly the behaviour of setup on > various systems at the moment, in the following ways: > > * I don't know how, and did not bother too much about emulating the > "access denied" when the user rejects the privilege elevation. I don't think that much of a problem. If the user refuses the elevation, setup won't run. That's as much message as one needs, I think. > * Under x86 (32bit), where the user has performed the rename magic that > normally circumvents the UAC Installer Detection Technology, setup > will still behave as if they hadn't and continue to try to elevate. > IMO this is minor, but if we were going for 100% compatibility, we > could check the exe filename against the same list that cygports uses, > and avoid the privilege elevation attempt: > > /usr/share/cygport/lib/src_postinst.cygpart:1112: find * -type > f -executable -a \( -name '*instal*.exe' -o -name '*patch*.exe' -o > -name '*setup*.exe' -o -name '*update*.exe' \) -print0 | \ I don't know if that's really needed anymore. Your patch provides a nice workaround, the --no-admin option. > * Under XP (32 bit... I don't know about any other archs (if they XP 64 bit exists :) > exist?) or other XP like editions (server???)), for a > non-Administrator the attempt to elevate privilege is also an extra > behaviour that wouldn't have been normally encountered. Again, it > may have been easy to detect that and do something about it too. XP and Server 2003 don't know the concept anyway, so calling GetVersion and skipping the entire elevation code if the result shows we're running on a pre-Vista system should do it. Something like this: if (LOWORD (GetVersion ()) >= _WIN32_WINNT_VISTA) { ...do the elevate thingy... } > Another bit of polish this patch needs is a effective way to close off > logging once and for all when we are about to call ShellExecuteEx. > Putting in the line: > > + l->msg.clear(); > > staved off the doubling up of logging when LogFile::exit was being > called. But unfortunately a bunch of newlines where being logged > instead. I never got around to knocking all that on the head. Hmm, that should be fixable. AFAICS, LogFile::log_save doesn't check if tstr is longer than 0: if (tstr[strlen (tstr) - 1] != '\n') f->write ("\n", 1); Does it help to write the NL only if there was some non-empty string? if (strlen (tstr) > 0 && tstr[strlen (tstr) - 1] != '\n') f->write ("\n", 1); ? > >Is that what we want? Or should the process only be elevated when > >started by a non-elevated admin as I proposed. I'm not sure, really. > > If I understand right, you were proposing that if the user was not an > Admin at all, then just let them run as they were. > > As I wrote earlier, it seemed from discussion that it was desirable (if > not pseudo policy) that regular Cygwin users run with privilege > elevated. And knowing of various features built into setup that require > elevated privilege, eg. replace on boot, I can see why that is. Yes, as I said, that makes sense. I think your approach is fine. > But I am happy to be guided either way. I can help out too, but as you > can see by the latency in my communication/implementation, I am not > a pillar of reliability :-( There's no immediate pressure, I think. Feel free to submit your patch when you think you're ready, or if you want some testing. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-10-15 16:00 ` Corinna Vinschen @ 2013-11-04 11:59 ` Corinna Vinschen 2013-11-06 11:18 ` Shaddy Baddah 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2013-11-04 11:59 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 6006 bytes --] Hi Shaddy, any news? Thanks, Corinna On Oct 15 18:00, Corinna Vinschen wrote: > On Oct 16 02:18, Shaddy Baddah wrote: > > On 15/10/13 23:22, Corinna Vinschen wrote: > > >On Oct 15 21:21, Shaddy Baddah wrote: > > >>On 15/10/13 20:08, Corinna Vinschen wrote: > > >>>[...] > > >thanks for letting us know and your patch. I had a look and it looks > > >good for a start. You just call the CheckTokenMembership function, > > >though. The problem is, you won't know if the process has been started > > >by a non-admin or by an admin without elevation. So you always call > > >ShellExecute if setup is started without admin rights, for non-admins > > >and non-elevated admins alike, unless the --no-admin option is given. > > > > Yes that is deliberate. Initially I coded this for how I viewed was > > desirable, that being that it would use CheckTokenMembership to see if > > it was elevated (or just run as Administrator on XP). If it was not, it > > would attempt to elevate using "runas" flag. If that was rejected, it > > would carry on. The --no-admin was still used as per the patch > > submitted to avoid infinite loop just in-case ShellExecuteEx didn't > > honour "runas" and just ran setup all over again with no Administrator > > rights. > > > > However I sensed from previous discussions that really it was desirable > > to steer users towards running as Admin/elevated privilege. Unless they > > really knew what they were doing. So much so that building a custom > > setup.exe was being recommended without much discussion of an > > alternative... until now. > > > > So this patch tries to be as backwards compatible as possible. That is, > > unless the user has already explicitly elevated privilege (context > > menu -> Run as ...), setup.exe forces an attempt. And fails if it does > > not elevate. The forced attempt can be avoided by explicitly specifying > > --no-admin. > > Yeah, that makes sense. > > > The patch I provided doesn't match exactly the behaviour of setup on > > various systems at the moment, in the following ways: > > > > * I don't know how, and did not bother too much about emulating the > > "access denied" when the user rejects the privilege elevation. > > I don't think that much of a problem. If the user refuses the elevation, > setup won't run. That's as much message as one needs, I think. > > > * Under x86 (32bit), where the user has performed the rename magic that > > normally circumvents the UAC Installer Detection Technology, setup > > will still behave as if they hadn't and continue to try to elevate. > > IMO this is minor, but if we were going for 100% compatibility, we > > could check the exe filename against the same list that cygports uses, > > and avoid the privilege elevation attempt: > > > > /usr/share/cygport/lib/src_postinst.cygpart:1112: find * -type > > f -executable -a \( -name '*instal*.exe' -o -name '*patch*.exe' -o > > -name '*setup*.exe' -o -name '*update*.exe' \) -print0 | \ > > I don't know if that's really needed anymore. Your patch provides a > nice workaround, the --no-admin option. > > > * Under XP (32 bit... I don't know about any other archs (if they > > XP 64 bit exists :) > > > exist?) or other XP like editions (server???)), for a > > non-Administrator the attempt to elevate privilege is also an extra > > behaviour that wouldn't have been normally encountered. Again, it > > may have been easy to detect that and do something about it too. > > XP and Server 2003 don't know the concept anyway, so calling GetVersion > and skipping the entire elevation code if the result shows we're running > on a pre-Vista system should do it. Something like this: > > if (LOWORD (GetVersion ()) >= _WIN32_WINNT_VISTA) > { > ...do the elevate thingy... > } > > > Another bit of polish this patch needs is a effective way to close off > > logging once and for all when we are about to call ShellExecuteEx. > > Putting in the line: > > > > + l->msg.clear(); > > > > staved off the doubling up of logging when LogFile::exit was being > > called. But unfortunately a bunch of newlines where being logged > > instead. I never got around to knocking all that on the head. > > Hmm, that should be fixable. AFAICS, LogFile::log_save doesn't > check if tstr is longer than 0: > > if (tstr[strlen (tstr) - 1] != '\n') > f->write ("\n", 1); > > Does it help to write the NL only if there was some non-empty string? > > if (strlen (tstr) > 0 && tstr[strlen (tstr) - 1] != '\n') > f->write ("\n", 1); > > ? > > > >Is that what we want? Or should the process only be elevated when > > >started by a non-elevated admin as I proposed. I'm not sure, really. > > > > If I understand right, you were proposing that if the user was not an > > Admin at all, then just let them run as they were. > > > > As I wrote earlier, it seemed from discussion that it was desirable (if > > not pseudo policy) that regular Cygwin users run with privilege > > elevated. And knowing of various features built into setup that require > > elevated privilege, eg. replace on boot, I can see why that is. > > Yes, as I said, that makes sense. I think your approach is fine. > > > But I am happy to be guided either way. I can help out too, but as you > > can see by the latency in my communication/implementation, I am not > > a pillar of reliability :-( > > There's no immediate pressure, I think. Feel free to submit your > patch when you think you're ready, or if you want some testing. > > > Thanks, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-11-04 11:59 ` Corinna Vinschen @ 2013-11-06 11:18 ` Shaddy Baddah 2013-11-06 13:21 ` Shaddy Baddah 0 siblings, 1 reply; 11+ messages in thread From: Shaddy Baddah @ 2013-11-06 11:18 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 878 bytes --] Hi Corinna, On Nov 04 22:59, Corinna Vinschen wrote: > any news? Sorry, yes. I have seen the emails (I do like cats :-D). I shouldn't offer excuses, but two concepts can explain my time deficit in the intervening period: terrible twos and various viruses (non computer). Kicked into action ;-) I've been sneaking time away from my domestic situation over the last couple of nights. I've worked out a better approach for the logging. It was quite simple, but my early attempts to understand the logging code were rushed. I still want to implement and test excluding enforced elevation as a default on XP, as I am sure it will be a nuisance. But I'll publish that as a separate patch in a couple of hours from now (I expect it should be a straightforward application of the code snippet you suggested). But here's the base patch attached in any case. -- Regards, Shaddy [-- Attachment #2: setup-sans-admin-november.patch.gz --] [-- Type: application/x-gzip, Size: 3208 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-11-06 11:18 ` Shaddy Baddah @ 2013-11-06 13:21 ` Shaddy Baddah 2013-11-06 13:43 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Shaddy Baddah @ 2013-11-06 13:21 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 605 bytes --] Hi, On Nov 06 22:16, Shaddy Baddah wrote: > On Nov 04 22:59, Corinna Vinschen wrote: >> any news? > > > I still want to implement and test excluding enforced elevation as a > default on XP, as I am sure it will be a nuisance. But I'll publish > that as a separate patch in a couple of hours from now (I expect it > should be a straightforward application of the code snippet you > suggested). Please find the patch with this check as setup-sans-admin-november-optional-seq2.patch.gz. I also have enhanced a log file message as setup-sans-admin-november-optional-seq3.patch.gz. -- Regards, Shaddy [-- Attachment #2: setup-sans-admin-november-optional-seq2.patch.gz --] [-- Type: application/x-gzip, Size: 404 bytes --] [-- Attachment #3: setup-sans-admin-november-optional-seq3.patch.gz --] [-- Type: application/x-gzip, Size: 310 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-11-06 13:21 ` Shaddy Baddah @ 2013-11-06 13:43 ` Corinna Vinschen 2013-11-06 16:12 ` Christopher Faylor 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2013-11-06 13:43 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 1071 bytes --] Hi Shaddy, On Nov 7 00:20, Shaddy Baddah wrote: > Hi, > > On Nov 06 22:16, Shaddy Baddah wrote: > >On Nov 04 22:59, Corinna Vinschen wrote: > >>any news? > > > > > > >I still want to implement and test excluding enforced elevation as a > >default on XP, as I am sure it will be a nuisance. But I'll publish > >that as a separate patch in a couple of hours from now (I expect it > >should be a straightforward application of the code snippet you > >suggested). > > Please find the patch with this check as > setup-sans-admin-november-optional-seq2.patch.gz. > > I also have enhanced a log file message as > setup-sans-admin-november-optional-seq3.patch.gz. Looks fine to me. When you're ready to go, please send the complete patch in cleartext (not compressed) with a ChangeLog entry. I will give it a try and apply soon, so we can finally get rid of this problem. Thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-11-06 13:43 ` Corinna Vinschen @ 2013-11-06 16:12 ` Christopher Faylor 2013-11-06 16:50 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Christopher Faylor @ 2013-11-06 16:12 UTC (permalink / raw) To: cygwin-apps On Wed, Nov 06, 2013 at 02:43:22PM +0100, Corinna Vinschen wrote: >Looks fine to me. When you're ready to go, please send the complete >patch in cleartext (not compressed) with a ChangeLog entry. I will >give it a try and apply soon, so we can finally get rid of this problem. And, I'll be standing by to generate a new version of setup.exe as soon as the patch goes in. Then we can just sit back and tell people to upgrade when they complain. Ah, WJVM. cgf ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe) 2013-11-06 16:12 ` Christopher Faylor @ 2013-11-06 16:50 ` Corinna Vinschen 0 siblings, 0 replies; 11+ messages in thread From: Corinna Vinschen @ 2013-11-06 16:50 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 718 bytes --] On Nov 6 11:12, Christopher Faylor wrote: > On Wed, Nov 06, 2013 at 02:43:22PM +0100, Corinna Vinschen wrote: > >Looks fine to me. When you're ready to go, please send the complete > >patch in cleartext (not compressed) with a ChangeLog entry. I will > >give it a try and apply soon, so we can finally get rid of this problem. > > And, I'll be standing by to generate a new version of setup.exe as soon > as the patch goes in. > > Then we can just sit back and tell people to upgrade when they complain. > > Ah, WJVM. *evil laughter* Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-11-06 16:50 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <6CF2FC1279D0844C9357664DC5A08BA215F56A@MLBXV06.nih.gov> [not found] ` <523F9C4F.6010109@cygwin.com> [not found] ` <6CF2FC1279D0844C9357664DC5A08BA215F9C7@MLBXV06.nih.gov> 2013-10-15 9:08 ` cannot run setup64.exe without admin privileges (even if renamed foo.exe) Corinna Vinschen 2013-10-15 10:21 ` Shaddy Baddah 2013-10-15 12:22 ` Corinna Vinschen 2013-10-15 15:18 ` Shaddy Baddah 2013-10-15 16:00 ` Corinna Vinschen 2013-11-04 11:59 ` Corinna Vinschen 2013-11-06 11:18 ` Shaddy Baddah 2013-11-06 13:21 ` Shaddy Baddah 2013-11-06 13:43 ` Corinna Vinschen 2013-11-06 16:12 ` Christopher Faylor 2013-11-06 16:50 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).