Closed bartoszkosiorek closed 4 years ago
I think I've seen this worked around by using a shell from pkgsrc, we may want to investigate going back to bootstrapping our own and using it for everything.
For my own project I would like to change the default shebang for wrappers. It seems that it could be modified in: https://github.com/NetBSD/pkgsrc/blob/trunk/pkgtools/pkg_alternatives/files/wrapper.sh#L1
Do you know by which option the __SH__
or @SH@
could be set?
I think it is set to the value of the SHELL environment variable during bootstrap?
Bartosz notifications@github.com schrieb am Fr., 12. Juni 2020, 16:13:
For my own project I would like to change the default shebang for wrappers. It seems that it could be modified in:
https://github.com/NetBSD/pkgsrc/blob/trunk/pkgtools/pkg_alternatives/files/wrapper.sh#L1
Do you know by which option the SH or @SH@ could be set?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NetBSD/pkgsrc/issues/66#issuecomment-643291989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGTQGVY6SWRFL4KFGVY6R3RWIZYVANCNFSM4N4F3IVA .
Simplest way is:
$ cd pkgsrc/pkgtools/pkg_alternatives
$ bmake TOOLS_PLATFORM.sh=/opt/pkg/bin/bash install
or whatever shell you want to use outside of /bin
.
@jperkin I have found also WRAPPER_SH
variable in settings:
https://github.com/NetBSD/pkgsrc/blob/pkgsrc-2019Q1/mk/wrapper/wrapper-defs.mk#L41
No, that's something completely different (and something you're unlikely to be using).
What do you think about idea, of use bash from pkgsrc/shells/bash
package by pkg_alternatives
for wrappers?
It will resolve such kind of issues, but it will be additional dependency to shells/bash
.
As a local change it would be fine, nothing depends on pkg_alternatives
so you aren't running any risks during upgrades etc.
For a wider pkgsrc fix we'll need to look into what the current status of shells/pdksh
is on Darwin by running some bulk builds, and then if it looks ok consider switching bootstrap over to using it by default.
After set TOOLS_PLATFORM.sh=/usr/local/pkg/bin/bash
, the wrappers have changed shebang correctly.
I will try to overwrite TOOLS_PLATFORM.sh
variable in pkg_alternatives/Makefile
and add dependency, to use the default shells/bash
shell.
I have build the shells/pdksh
without problems.
@jperkin Do you know how to setup shell from pkgsrc globally in bootstrap? The bootstrap tools are defined here: https://github.com/NetBSD/pkgsrc/blob/trunk/mk/tools/tools.Darwin.mk#L100
How these paths needs to be set properly to use pkgsrc shell and how add dependency to boostrap?
Yes, I'm currently testing this in a bulk build.
Could you please share the code with updated bootstrap? I would like to start my own testing.
For testing I'm just using bootstrap with the --full
argument, this ensures that pdksh is bootstrapped and set as the default shell. If it looks ok then the permanent fix would be adding need_ksh=true
to the Darwin setup section, probably being limited to OS releases that ship with SIP.
@jperkin Do you know if the zsh
could be used by default for macOS/Darwin, as it is default shell:
https://www.theverge.com/2019/6/4/18651872/apple-macos-catalina-zsh-bash-shell-replacement-features
?
One of the build hosts crashed over the weekend (Catalina is highly unreliable), I'll need to restart it.
As for zsh, I wouldn't recommend it, it's not designed to be a fast POSIX-only shell, but more as a feature-full interactive shell.
I think I found the root cause of my problems:
During run bootstrap, I was using SH=/bin/bash
environment variable:
SH=/bin/bash ./bootstrap --prefix "$PKGSRC_PREFIX" --prefer-pkgsrc yes --workdir "$WORK_DIR" $__UNPRIVILEGED
After removing SH=/bin/bash
, and use default shell, most/all of alternatives are using #!/usr/local/pkg/bin/bash
shebang (/usr/local/pkg/
is a directory where pkgsrc is installed).
Do you know why it choose the bash instead of sh, as defined here? https://github.com/NetBSD/pkgsrc/blob/trunk/mk/tools/tools.Darwin.mk#L100
The /usr/local/pkg/etc/mk.conf
content:
# Example /usr/local/pkg/etc/mk.conf file produced by bootstrap-pkgsrc
# Tue Jun 16 11:12:26 CEST 2020
.ifdef BSD_PKG_MK # begin pkgsrc settings
ABI= 64
PKGSRC_COMPILER= clang
CC= clang
CXX= clang++
CPP= ${CC} -E
CLANGBASE= /usr
UNPRIVILEGED= yes
PKG_DBDIR= /usr/local/pkg/pkgdb
LOCALBASE= /usr/local/pkg
VARBASE= /usr/local/pkg/var
PKG_TOOLS_BIN= /usr/local/pkg/sbin
PKGINFODIR= info
PKGMANDIR= man
PREFER_PKGSRC= yes
MAKE_JOBS=8
SKIP_LICENSE_CHECK=yes
WRKOBJDIR=/private/var/tmp/pkgsrc-obj
X11_TYPE=modular
RUBY_VERSION_DEFAULT=25
ALLOW_VULNERABLE_PACKAGES=yes
PREFER_PKGSRC= yes
PKG_OPTIONS.libfetch+= openssl
INSTALL_UNSTRIPPED=no
STRIP_BINARIES=yes
PKGSRC_USE_RELRO=full
BUILDLINK_USE_HARDLINKS=no
.endif # end pkgsrc settings
@jperkin Do you find any issue with building ksh
by default in bootstrap?
Bootstrap will default to /bin/sh
(i.e. bash) unless you override SH
in the bootstrap environment. If it's using /usr/local/pkg/bin/bash
then that will be from a setting you have somewhere (you mentioned earlier about patching things so it's probably from that).
The bulk build isn't finished yet, they usually take around 3 days to complete on macOS from scratch.
FWIW it's currently at 17380/22794, producing 13451 packages, so looks reasonable so far.
Thanks. I found an issue in my internal scripts.
After enabling need_ksh
on Darwin, the shell used by pkgsrc (pdksh
) will be completely independent from what is installed on system (etc. /bin/bash
or /bin/zsh
).
So it will resolve issue with: https://support.apple.com/en-us/HT208050
Apple could remove /bin/bash and /bin/zsh and the pkgsrc will be still working with shells/pdksh
.
Am I right?
I've posted the results of the bulk build along with a patch for bootstrap here for review: http://mail-index.netbsd.org/tech-pkg/2020/06/18/msg023387.html
@jperkin Thanks for your patch!
Could you please enable need_ksh=yes
as default, and disable it only on old systems?
Otherwise the versions needs to be updated once the new macOS version will be released.
Something similar to: https://github.com/NetBSD/pkgsrc/pull/67/files
@jperkin I think every package, which use pkg_alternatives
, should have running dependency on shells/pdksh
shell. Otherwise, it could happen that the application wrapper couldn't be run due to missing pdksh
.
That would already be handled on account of it being a BOOTSTRAP_PKG
.
After setting need_ksh
, almost all +INSTALL
scripts are using default shell (for macOS it will be pdksh
).
For example pkg_alternatives
:
https://github.com/NetBSD/pkgsrc/blob/trunk/pkgtools/pkg_alternatives/INSTALL
But for some packages, the shell is hardcoded. For example for pkg_install
:
https://github.com/NetBSD/pkgsrc/blob/trunk/pkgtools/pkg_install/INSTALL#L1
Do you know the reason for that? Why the default shell is not used for pkg_install
?
I think just an oversight, though it's probably a good idea to be as safe as possible for critical packages and there's nothing in the pkg_install
INSTALL script that would cause problems for any Bourne shell.
What else needs to be done to enable ksh
by default for macOS bootstrap?
After running into a separate issue in pdksh I went an alternative route and implemented mksh as a bootstrap shell. I'm just waiting on review of http://mail-index.netbsd.org/tech-pkg/2020/06/29/msg023478.html and will, once that's imported, switch macOS over to it.
The issue is with pkg_alternatives
, not SIP.
Environment variables passed to the wrapper script are not intended for the shell, but the process it will spawn. This is the reason SIP does not allow passing DYLD_*
environment variables directly to the shell. Replacing /bin/bash
with mksh
does not solve the issue where environment variables intended for the child are also passed to the parent. Fixing this issue is the responsibility of pkg_alternatives
, not pkgsrc
. Commit https://github.com/NetBSD/pkgsrc/commit/8fc2bb66534de42d08fb9f93333af6904f6c6782, currently the 7th largest commit by number of insertions in the pkgsrc repository, is merely part of a temporary fix that does nothing to address the potentially harmful use of DYLD_*
variables.
For the reasons outlined above, all commits related to this issue should be reverted.
Regardless of whether there are additional issues with pkg_alternatives that need resolving, there are still legitimate reasons for switching to a non-system shell on SIP-enabled systems, and this is not going to be reverted.
Closing this one out for now after mksh was imported and set as the bootstrap shell, if there are additional issues in pkg_alternatives that need looking at then they can be logged in separate tickets. Thanks.
I have commented on https://github.com/NetBSD/pkgsrc/commit/9545f5f3f93a0d2594c8db1fee928504e271dbc7 as not to clutter the discussion on this issue.
@jperkin Thank you very much Jonathan for fixing this issue. It is fixing all our SIP related issues for all projects in my company.
Due to System Integrity Protection (SIP) on macOS systems, the binaries from the
/bin
(eg./bin/bash
) are not allowed to handle this environment variables. More information: https://support.apple.com/en-us/HT204899Example of SIP:
./test.sh
fileDYLD_LIBRARY_PATH=/lalala ./test.sh
Result:
$ DYLD_LIBRARY_PATH=/lalala ./test.sh
The current generated alternative script files on macOS from the
pkg_alternatives package
are having as interpreter/bin/bash
, eg.pip3
:This is a bit problematic in case of macOS as due to SIP protection for example declared environment variable like
DYLD_LIBRARY_PATH
is rejected.This will lead eventually to problems for trying to do things like
DYLD_LIBRARY_PATH=/path_with_dylibs /usr/local/pkg//bin/ctest
which is pretty common.