FAQ
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

Search Discussions

  • Jan Dubois at May 15, 2014 at 5:25 pm

    On Thu, May 15, 2014 at 8:35 AM, kmx wrote:
    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). [...]
    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 at May 15, 2014 at 6:10 pm
    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


    On Thu, May 15, 2014 at 1:25 PM, Jan Dubois wrote:
    On Thu, May 15, 2014 at 8:35 AM, kmx wrote:
    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). [...]
    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
  • Jan Dubois at May 15, 2014 at 6:27 pm

    On Thu, May 15, 2014 at 11:10 AM, Chris Marshall wrote:
    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 at May 15, 2014 at 8:27 pm

    On 15.5.2014 20:27, Jan Dubois wrote:
    On Thu, May 15, 2014 at 11:10 AM, Chris Marshallwrote:
    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.
    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.
    Yes, exactly the same issue and I guess also the solution will be the same :)

    Thanks.

    --
    kmx

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupwin32-vanilla @
categoriesperl
postedMay 15, '14 at 3:36p
activeMay 15, '14 at 8:27p
posts5
users3
websitestrawberryperl.com

3 users in discussion

Kmx: 2 posts Jan Dubois: 2 posts Chris Marshall: 1 post

People

Translate

site design / logo © 2019 Grokbase