L.Allan-pbio wrote:
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
files there.
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
progress).
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.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
