Non-Admin can't install at all when <run-privileged /> is set

Description

When an installer is created with <run-privileged /> the created exe file is started with privilege elevation, opening a user selection dialog, so that an Admin user can be selected. But selecting a non-admin user results in a "This directory can not be written! Please choose another directory!" (UserPathPanel.notwritable) error message later when selecting a directory, even when the given directory is writable by the user.

I guess, during further installation, again, the program files directory is checked for write access and results in this message (am I right?). So, the message is completely misleading, because the selected directory may be writable by the non-admin user.

Either the run-privileged should be taken serious and the selected user must already have Admin rights (e.g. because the installer really needs it for proper operation) before starting the installer and giving the error, but I would prefer that the selected directory is checked for write access. This would come much closer to the real intention of the privilege elevation dialog: You may want to install a program as admin by default, but as unprivileged user selecting a writable directory makes it possible to install and use the software anyway.

My favorite universal solution could look like this:
By giving an attribute

the installing user must have admin rights for installation.
By using the default <run-privileged />-tag the installing user can select a non-admin account and he can install the software into a private writable directory.

Personally, for me the second option is important: to only start with the dialog, because the default installation directory is in program files and a usual user doesn't have write access to it. Showing this dialog gives him the background, that he either needs admin rights or he must select another directory where he has write access to. This is the common scenario in a business environment - the user doesn't have admin rights, but I want to give him the chance to install the software into a local folder.

Environment

Windows XP Professional

Activity

Show:
Adam Jurcik
June 17, 2018, 10:04 PM

I also experienced this issue. I created a workaround for me which sets TargetPanel.dir.{windows, unix } using dynamicvariable based on conditions that evaluate whether the installation is run elevated (or sudoed). I can share this on demand.

Robert Lauriston
June 8, 2018, 3:02 PM

Slightly kludgy workaround: don't specify a default path.

Assignee

Unassigned

Reporter

Former user

Impact

None

Components

Affects versions

Priority

Medium