Home directory was not created

[Brian Inglis]

On 2021-03-03 04:22, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
>> -----Original Message-----
>> From: Cygwin <cygwin-bounces@cygwin.com> On Behalf Of Brian Inglis
>> Sent: 02 March 2021 19:57
>>
>> On 2021-03-02 01:08, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
>>> -----Original Message-----
>>> From: KAVALAGIOS Panagiotis (EEAS-EXT)
>>> Sent: 02 March 2021 08:15
>>
>>> zip 358KB > 256KB too big I think
> 
> OK, the mystery has been resolved. There should be at least an e-mail notification to indicate that limitation. It is not polite for the list to simply ignore the submissions without saying anything :)
> 
>> All postinstall steps failed because of BLODA or installation path:
>>
>> 2021/02/09 17:48:06 running: C:\Program Files\Cygwin\bin\dash.exe
>> "/etc/postinstall/0p_000_autorebase.dash"
>>         0 [main] dash (2296) shared_info::initialize: size of shared memory region
>> changed from 49080 to 40888
>> 2021/02/09 17:48:20 abnormal exit: exit code=-1073741819 ...
>>
>> Installing under Program\ Files causes issues because of space in path names
>> and BLODA-like AV protections on those paths.
> 
> The installation is performed by powershell script that runs with the super admin (system user/nt authority) from local repository that normally bypasses all those kind of AV restrictions. I start it from the Cygwin icon that runs mintty under the hood. I don't know who took those 8KB from the script's shared memory, but indeed it looks like a BLODA interference. I will ask the package to be re-installed.
> 
> I have checked the installation logs and there was no error returned from the setup program. Shouldn't return non-zero value so that the package manager is notified about that issue? Or maybe it Is returned and I failed to propagate that in my .bat file:
> 
> ---------
> @echo off
> @echo Starting Cygwin installation
> 
> "%cd%\setup-x86_64.exe" -q -A -L -l "%cd%\cygwin-repo" -R "C:\Program Files\Cygwin" -P autoconf,automake,bash-completion,binutils,curl,dos2unix,emacs,git,git-svn,gnupg2,inetutils,jq,konsole,mc,openssh,patchutils,perl,psmisc,python2,python3,rsync,ruby,subversion,tcsh,tmux,unzip,vim,vim-common,wget,xinit,xlaunch,xorg-server,xorg-server-common,xorg-server-xorg,xorg-x11-fonts-dpi100,xorg-x11-fonts-dpi75,xorg-x11-fonts-Type1,xorg-x11-fonts-misc,xterm,zip
> ---------
> 
> Does it need "exit /b %errorlevel%"?
> 
> We are running Cygwin from "C:\Program Files" for years without issue. A space in the directory name is a very supported character for Unix and Unix-like systems as well. A quoted path that includes a space character is enough to resolve any possible issues. Unfortunately on an enterprise environment, program execution is only allowed under "C:\Program Files", so we haven't left many options. We do have prepared another directory without spaces for programs that even refuse to be installed on a path containing spaces (call me Weblogic and ColdFusion servers), but Cygwin accepts happily to be installed on a directory with spaces with a small warning. I would need to justify the non-compliance of Cygwin to be moved off "C:\Program Files" and so far I don't have any evidence.

You have just stated that there are at least two exceptions that you are aware 
of installation under Program Files, so installation and execution is not "only 
allowed" there.
Cygwin includes a lot of data files and your home directories under there and 
Windows now, and moreso in the future, disables and disallows modifications and 
changes there without elevation, or bypass of the policies requiring elevation.

The "small" warning is your interpretation, but feel free to downplay that 
evidence and ignore it at your peril, as you may not soon notice the security 
and/or integrity problems that occur because of programs and all the scripts 
that don't handle spaces safely, especially in crafted path names and argument 
values, or the problems that occur because Windows security may silently prevent 
user changes or file creation, or require security policy bypasses to allow them 
to do whatever they like under those paths.

Read up on OS/command/shell injection vulnerabilities and why patching bash for 
shellshock was just the start of a massive effort required to change every 
command in every script, and every program invoked by every script, to support 
and use features that limit the opportunities for, and effects of, vulnerability 
injections into directory and file paths and names, program and script names, 
options, and argument values.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]