Strawberry Perl MSI installer

[kmx]

Hi,

We have many reports related to problems with installing strawberry perl
via MSI installer. Like troubles with installing on non-C: drive, troubles
with installing on a machine completely without C: drive, some permission
related issues etc.

I have prepared redesigned version of MSI (it is 5.19.11.4) and made it
available at http://strawberryperl.com/beta/ - visually it looks exactly as
the old installer but guts changed a lot.

If you have experienced in past any troubles with MSI installer or if you
can test it on a unusual machine (like one with system drive D: without
drive C:) or if you can test it on a box with some unusual UAC settings -
please get the latest beta from URL above and check if the MSI installer
works for you.

In case of troubles run:
c:\anydir> msiexec /l*vx install.log /i strawberry-perl-5.19.11.4-64bit.msi
and send me install.log (off-list)

The second issue is related to our highly respected sponsor <ad>
https://auditsquare.com </ad> as their security checker (even FREE version)
reports a security warning related to strawberry perl installation. In
short it says that PATH contains directories (c:\strawberry\c\bin
c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by
too wide group of users (built-in Users or even Authenticated Users).

We currently do not explicitly set any filesystem ACL therefore
C:\strawberry directory gets some ACL inherited from C:\ which is probably
mostly fine but might be a trouble if you choose another directory (or
another drive) which parent dir has some strange and/or unexpected ACL. I
feel that our MSI should probably set some filesystem ACL on C:\strawberry
(which is supported by WiX Toolset we use for MSI creation) but I am not
sure what it should be (e.g. Administrators+SYSTEM/FullControl,
Users/Read+Execute ?). Any ideas or preferably experiences with building
MSI are welcome.

--
kmx

[Jan Dubois]

Post by kmx
it says that PATH contains directories (c:\strawberry\c\bin
c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by
too wide group of users (built-in Users or even Authenticated Users).

[...]

Post by kmx
I feel that our MSI should probably set some filesystem ACL on C:\strawberry
(which is supported by WiX Toolset we use for MSI creation) but I am not
sure what it should be (e.g. Administrators+SYSTEM/FullControl,
Users/Read+Execute ?). Any ideas or preferably experiences with building MSI
are welcome.

The problem is that if you set a more restrictive ACL, then you will
always need to run from an elevated shell to install additional
modules from CPAN. So you have to make a choice between convenience
and security. My personal opinion: setting a restrictive ACL makes
sense on a server, but not on a user's desktop.

Cheers,
-Jan

[Chris Marshall]

Not familiar with MSI details but I hope any changes
won't be a problem for SPP which is useful because
it *doesn't* require special permissions---just enough
to create the folder...

--Chris

Post by kmx

Post by kmx
it says that PATH contains directories (c:\strawberry\c\bin
c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by
too wide group of users (built-in Users or even Authenticated Users).

[...]

Post by kmx
I feel that our MSI should probably set some filesystem ACL on

C:\strawberry

Post by kmx
(which is supported by WiX Toolset we use for MSI creation) but I am not
sure what it should be (e.g. Administrators+SYSTEM/FullControl,
Users/Read+Execute ?). Any ideas or preferably experiences with building

MSI

Post by kmx
are welcome.

The problem is that if you set a more restrictive ACL, then you will
always need to run from an elevated shell to install additional
modules from CPAN. So you have to make a choice between convenience
and security. My personal opinion: setting a restrictive ACL makes
sense on a server, but not on a user's desktop.
Cheers,
-Jan

...

[Jan Dubois]

Post by Chris Marshall
Not familiar with MSI details but I hope any changes
won't be a problem for SPP which is useful because
it *doesn't* require special permissions---just enough
to create the folder...

This has nothing to do with MSI, but with putting a directory on the
PATH to which the user has write access. Essentially all scripting
languages do this to allow the user to install additional modules
easily, but security companies like to put out alerts about this...

It is not a new issue; here is the ActiveState position about the same
issue with ActivePerl:

https://community.activestate.com/node/9199

TL;DR: The default is more convenient for most users; it is trivial
for users to apply more restrictive ACLs if they are bothered about
it.

Cheers,
-Jan

[kmx]

Post by Jan Dubois

Post by Chris Marshall
Not familiar with MSI details but I hope any changes
won't be a problem for SPP which is useful because
it *doesn't* require special permissions---just enough
to create the folder...

This has nothing to do with MSI, but with putting a directory on the
PATH to which the user has write access. Essentially all scripting
languages do this to allow the user to install additional modules
easily, but security companies like to put out alerts about this...

With ZIP and Portable it completely in user's hand how he|she created
destination directory and with what filesystem permissions. This will not
change.

Post by Jan Dubois
It is not a new issue; here is the ActiveState position about the same
https://community.activestate.com/node/9199
TL;DR: The default is more convenient for most users; it is trivial
for users to apply more restrictive ACLs if they are bothered about
it.

Yes, exactly the same issue and I guess also the solution will be the same :)

Thanks.

--
kmx