On Jul 23 15:08, Charles Wilson wrote: > On 7/23/2013 2:46 PM, Corinna Vinschen wrote: > >On Jul 23 14:14, Charles Wilson wrote: > >>>I believe your report has to do with error handling when attempting > >>>to modify the All User's Desktop, when you don't actually retain the > >>>elevated permissions necessary to do so. > > >>Is there are way for setup.exe to > >>delegate its elevated credentials down to /bin/bash, and thence to > >>mkshortcut.exe? Otherwise, even the *fix* for this bug will just > >>make it not hang or crash; it will still fail to modify the > >>all-users start menu/desktop. > > > >Setup does not give up any of it's permissions when starting the > >postinstall scripts via CreateProcess. The scripts have the same > >permissions as setup itself, which makes a lot of sense if you think > >about it. Missing permissions to change system dirs should only occur > >if setup has been started as non-admin, or if the UAC installer > >recognition has been switched off (affects only the 32 bit version). > > But even if /bin/bash is elevated, it doesn't follow that any of the > tools launched within a script -- via cygwin's fork/exec method -- > ALSO retain that elevation. > > Does it?
Yes, it does. CreateProcess propagates its own user token untouched. Weird question. Did you ever start an elevated shell and lost your admin permissions in a child process? If that would occur, nothing would work right in an admin shell. Even the `id' call would not show the admins group in your supplementary group list. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
