Re: Strawberry Perl MSI installer

2014-05-15 Thread kmx

On 15.5.2014 20:27, Jan Dubois wrote:

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...


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


Re: Strawberry Perl MSI installer

2014-05-15 Thread Jan Dubois
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


Re: Strawberry Perl MSI installer

2014-05-15 Thread 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



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
>


Re: Strawberry Perl MSI installer

2014-05-15 Thread Jan Dubois
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