limit.sh in Shellbox (formerly bin/ulimit5.sh in core) calls /bin/bash.
Some OS install Bash at another place e.g. /usr/local/bin/bash for FreeBSD.
Some OS don't ship bash by default.
In a first step, I will fix that to #!/usr/bin/env bash instead, so bash could be found in the path.
In a second step, we should see:
[ Documentation note to add ]
Our extension uses the timeout command, part of the GNU core utilities.
On BSD systems, you have to install the coreutils package to make this command available. If not, limits defined by the extension code will be ignored.
Gerrit change 47045 abandoned.
Gerrit change 47559 will do the job, replacing ulimit5.sh by a new script. This change is still to be improved to solve issues raised in this bug.
(In reply to comment #4)
Gerrit change #47559 will do the job, replacing ulimit5.sh by a new script.
This change is still to be improved to solve issues raised in this bug.
The patch was merged.
Dereckson: The remaining issues are what is listed as "In a second step, we should see:" in comment 0 here? In case you don't plan to work on them, feel free to reset the assignee and ASSIGNED status.
includes/limit.sh checks that /usr/bin/timeout exists and is executable before using it. Otherwise it simply runs the command without enforcing the wall clock limit. So not really a problem.
Feel free to suggest where to document it.
What's the status of this bug with the new includes/limit.sh ?
The current problem seems to be /bin/bash, hardcoded in includes/GlobalFunctions.php and in the recursive call through /usr/bin/timeout
Although wfShellExec() is only calling limit.sh on Linux (It has been like that since the stone age (r11789) but the basic limit features should work on other *nix).
I was just talking to a user on irc who's using busybox, which doesn't have bash installed.
We should probably be checking if /bin/bash is executable (Sometimes bsds might have bash), instead of checking if linux.
Removing target milestone that was in the past.
If you want this in a specific release, have a good reason AND you are willing to find resources to fix this bug, feel free to change it to something appropriate.
alasdairgmacdonald wrote:
I encountered this problem in the context of an imagemagick command for creation of thumbnails on a Synology NAS.
The NAS has /bin/ash by default, linked to busybox. But it doesn't have bash.
Without /bin/bash, the following command fails because of references to /bin/bash in includes/GlobalFunctions.php:
/bin/bash '/path/to/limit.sh' ''\''/usr/bin/convert'\'' -version' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=180; MW_CGROUP='\'''\''; MW_MEM_LIMIT=307200; MW_FILE_SIZE_LIMIT=10 2400; MW_WALL_CLOCK_LIMIT=180; MW_USE_LOG_PIPE=yes'
error is:
-ash: /bin/bash: not found
I've simplified subsequent commands to show only the imagemagick command and not the MW_ settings.
If I test ash instead of bash:
/bin/ash '/path/to/limit.sh' ''\''/usr/bin/convert'\'' -version'
error is:
/path/to/limit.sh: line 33: syntax error: bad substitution
So, ash [busybox] doesn't like my limit.sh.
After linking /bin/bash to /bin/ash or to /bin/busybox the error changes:
/bin/bash '/path/to/limit.sh' ''\''/usr/bin/convert'\'' -version'
error is:
/path/to/limit.sh: bash: applet not found
So, busybox still doesn't like limit.sh.
If I try to execute limit.sh directly:
/path/to/limit.sh ''\''/usr/bin/convert'\'' -version'
error is:
.sh: not found
(because, I think, my limit.sh has references to /bin/bash)
Of course there is a solution in my case and it is easy to apply, although it would not have been as simple if I didn't have bash already available in /opt, and even more problematic if I weren't able to add bash at all:
ln -s /opt/bin/bash /bin/bash
However it doesn't seem right to me that /bin/bash should be assumed to be present. When I only had this error to work on "-ash: /bin/bash: not found", I thought that the answer must be a MediaWiki configuration setting for the shell. Something like wgShell. Perhaps that would have security implications.
This isn't a solution for my environment:
echo $SHELL
/bin/ash
because of the aforementioned limitations of ash / busybox.
The only other global solution that I can think of is to test for various possible shells, one after the other. In which case the sequence for testing may matter, perhaps breaking environments that currently work.
(In reply to Platonides from comment #7)
The current problem seems to be /bin/bash, hardcoded in
includes/GlobalFunctions.php and in the recursive call through
/usr/bin/timeoutAlthough wfShellExec() is only calling limit.sh on Linux (It has been like
that since the stone age (r11789) but the basic limit features should work
on other *nix).