[sword-devel] BibleCS Installer: HKCU vs HKLM
dmsmith555 at yahoo.com
Tue Feb 14 11:24:11 MST 2006
>> If you do the leg work, I'll incorporate it. But at some point we
>> need to do a release. And at that point whatever is solid will make
>> the cut and be used. We can still work on it for the next release.
> I did some more research, and the more you look, the more complicated
> it seems to get. I'm ready to punt and proceed with the assumption
> that they need admin priv ... to both install and run.
> The problem doesn't look like it will go away. My impression is that
> more and more the guidance is to run with least privilege because that
> prevents most malware from being able to do their damage.
I'll "hide" the changes or save them off so we can revisit in a later
release. The only thing left after that is to conditionally remove the
installed modules when the last CrossWire family member is uninstalled
as indicated by the HKLM/Software/CrossWire key.
>>> However, you may be correct that a limited user will have problems
>>> writing to C:\Program Files ..... which presents a big problem. On
>>> my test computer, the C:\Program Files was created by my normal
>>> Admin account, which may prevent a subsequent limited user account
>>> from writing to it .... that might not be the case if the C:\Program
>>> Files was created on a computer that didn't have a previous Admin
>>> account established. Shucks.
>> I don't think that it matters. If it can't be written to on some
>> machines, but because of how the user upgraded to their current os,
>> then we shouldn't use that location.
>> That would be a show stopper. There must be an alternative location
>> for a limited user.
> I didn't find any .... that does seem like a show-stopper. The WinXp
> Logo requirement calls for installation to C:\Program Files, and being
> able to run as a limited user. Files like userpref.conf, options.conf,
> and other writable .conf files are supposed to go in C:\Documents and
> Settings\[CurrentUser]. It may be that the Microsoft .msi installer
> would need to be used to accomplish that.
NSIS has variables for those areas (it is actually [drive]:\Document and
Settings\[Current User]\Application Data\[my app])
but unless the SwordAPI changes to look there it won't work to put the
> If we didn't have 1.5.6 (and earlier) legacy, it perhaps might be
> worth wrestling with, but reinstalls to the existing location put the
> difficulty/effort/complexity beyond something I have
> time/experience/aptitude to work on. Sorry (and also for bringing up
> the issue without realizing the implications and thus slowing down
It is the challenge to dig deeper and not accept the simple or obvious
that leads to better solutions.
I learned a lot about NSIS that I will be able to use again.
No need for apology.
>>> There will probably be similar issues with SWORD_PATH ... a limited
>>> user can probably set this environment variable for just themselves,
>>> not all users.
>> Hopefully, WriteEnvStr has all that figured out. But we should check.
> I think you are correct.
More information about the sword-devel