Hello, # ls -l /usr/local/bin/execline-* -rwx------ 1 root wheel 8760 Dec 2 06:55 /usr/local/bin/execline-cd -rwx------ 1 root wheel 9080 Dec 2 06:55 /usr/local/bin/execline-umask I think this was an upstream issue that was fixed long before 2.9.0.0. https://git.skarnet.org/cgi-bin/cgit.cgi/execline/commit/package/modes?id=fc71200d67593c4a2d7b3105dc592c3ac96e725c https://git.skarnet.org/cgi-bin/cgit.cgi/execline/tree/package/modes?h=v2.9.0.0#n9 https://git.skarnet.org/cgi-bin/cgit.cgi/execline/tree/Makefile?h=v2.9.0.0#n119 I am yet to determine why an installation of execline 2.9.0.0 on FreeBSD does not set these bits today. # pkg info -l execline | grep bin | xargs stat -f '%p %N' 100755 /usr/local/bin/background 100755 /usr/local/bin/backtick 100755 /usr/local/bin/case 120700 /usr/local/bin/cd 100755 /usr/local/bin/define 100755 /usr/local/bin/dollarat 100755 /usr/local/bin/elgetopt 100755 /usr/local/bin/elgetpositionals 100755 /usr/local/bin/elglob 100755 /usr/local/bin/emptyenv 100755 /usr/local/bin/envfile 100755 /usr/local/bin/exec 100700 /usr/local/bin/execline-cd 100700 /usr/local/bin/execline-umask 100755 /usr/local/bin/execlineb 100755 /usr/local/bin/exit 100755 /usr/local/bin/export 100755 /usr/local/bin/fdblock 100755 /usr/local/bin/fdclose 100755 /usr/local/bin/fdmove 100755 /usr/local/bin/fdreserve 100755 /usr/local/bin/fdswap 100755 /usr/local/bin/forbacktickx 100755 /usr/local/bin/foreground 100755 /usr/local/bin/forstdin 100755 /usr/local/bin/forx 100755 /usr/local/bin/getcwd 100755 /usr/local/bin/getpid 100755 /usr/local/bin/heredoc 100755 /usr/local/bin/homeof 100755 /usr/local/bin/if 100755 /usr/local/bin/ifelse 100755 /usr/local/bin/ifte 100755 /usr/local/bin/ifthenelse 100755 /usr/local/bin/importas 100755 /usr/local/bin/loopwhilex 100755 /usr/local/bin/multidefine 100755 /usr/local/bin/multisubstitute 100755 /usr/local/bin/pipeline 100755 /usr/local/bin/piperw 100755 /usr/local/bin/posix-cd 100755 /usr/local/bin/posix-umask 100755 /usr/local/bin/redirfd 100755 /usr/local/bin/runblock 100755 /usr/local/bin/shift 100755 /usr/local/bin/trap 100755 /usr/local/bin/tryexec 120700 /usr/local/bin/umask 100755 /usr/local/bin/unexport 100755 /usr/local/bin/wait 100755 /usr/local/bin/withstdinas # pkg info execline execline-2.9.0.0 Name : execline Version : 2.9.0.0 Installed on : Tue Dec 27 17:44:14 2022 AEDT Origin : lang/execline Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : shells lang Licenses : ISCL Maintainer : crest@rlwinm.de WWW : https://www.skarnet.org/software/execline/ Comment : Lightweight non-interactive sh(1)-like scripting language Options : DOCS : on Shared Libs required: libskarnet.so.2.12 Shared Libs provided: libexecline.so.2.9 Annotations : FreeBSD_version: 1301000 repo_type : binary repository : FreeBSD Flat size : 923KiB Description : execline is a very light non-interactive scripting language, which is similar to /bin/sh. Simple shell scripts can be easily rewritten in the execline language, improving performance and memory usage. execline was designed for use in embedded systems, but works on most Unix flavors. execline features conditional loops, getopt-style option handling, filename globbing, and more. Meanwhile, its syntax is far more logical and predictable than the shell's syntax, and has no security issues. WWW: https://www.skarnet.org/software/execline/
It is interesting to note that the modes on posix-cd and posix-umask are set correctly. # xzcat execline-2.9.0.0~c00593d25b.pkg | tar t -v | grep -- 'bin.*-cd' lrwx------ 0 root wheel 0 Jul 4 08:09 /usr/local/bin/cd -> execline-cd -rwx------ 0 root wheel 8816 Jul 4 08:09 /usr/local/bin/execline-cd -rwxr-xr-x 0 root wheel 15016 Jul 4 08:09 /usr/local/bin/posix-cd (I also checked execline-2.6.0.1~f36133a160.txz, which was the oldest package in my cache. Same modes.) http://package21.nyi.freebsd.org/data/131amd64-default-qat/c610273231b4/logs/execline-2.9.0.0.log AFAICS, the only special treatment happens here: exec ./tools/install.sh -l execline-cd /wrkdirs/usr/ports/lang/execline/work/stage/usr/local/bin/cd exec ./tools/install.sh -l execline-umask /wrkdirs/usr/ports/lang/execline/work/stage/usr/local/bin/umask install.sh umasks to 077, so the symlink is created mode 0700. I don't see how that would impart any effect on the targets of these links, but it seemed too coincidental, so I thought I'd mention it in case it is somehow related to this problem.
I'll look into this as part of updating the ports to the January 2023 release.
I reproduced the problem both with execline 2.9.0.0 and 2.9.1.0 on FreeBSD 13.1/amd64 and am looking the execline build scripts as well as the port.
Done in bug #269439 Can the OP confirm?
(In reply to Fernando Apesteguía from comment #4) Hello, I built execline-2.9.1.0 from ports revision 7a9318b52f30. Modes on execline-cd and execline-umask remain the same. Still 0700 instead of 0755. The latter is expected. # xzcat execline-2.9.1.0.pkg | tar t -v | grep -- /bin/execline- -rwx------ 0 root wheel 8552 Feb 17 03:14 /usr/local/bin/execline-cd -rwx------ 0 root wheel 8872 Feb 17 03:14 /usr/local/bin/execline-umask # xzcat execline-2.9.1.0.pkg | tar t -v | grep -- /bin/posix- -rwxr-xr-x 0 root wheel 15792 Feb 17 03:14 /usr/local/bin/posix-cd -rwxr-xr-x 0 root wheel 12312 Feb 17 03:14 /usr/local/bin/posix-umask While the Jan '23 skaware update is much appreciated, I am afraid this bug remains.
Let's see what the maintainer has to say. Thanks for the feedback.
Created attachment 240186 [details] Patch overwriting the problematic permissions via pkg-plist I agree. The update to version 2.9.1.0 alone did not fix the problem. I traced the build process with dwatch execve and failed to quickly identify the culprit. According to execline's package/modes file the executables are supposed to be installed with mode 0755 instead of mode 0600. Running gmake install from the work directory (bypassing staging and packaging) does install them to /usr/local/bin with the expected permissions. I expect it's some annoying interaction between either gmake or execline's install.sh and port staging. For now the best I came up with is to just overwrite the permissions in pkg-plist.
(In reply to crest from comment #7) I'm sorry, I can't see how the proposed patch fixes the issue. It only bumps PORTREVISION. A missing "git add pkg-plist"?
Created attachment 240187 [details] 240186: Patch overwriting the problematic permissions via pkg-plist (this time with pkg-plist) Yes I forgot to add pkg-plist to the commit.
Committed, Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=97cc52875872928d12da8a128339ee18aaf8324b commit 97cc52875872928d12da8a128339ee18aaf8324b Author: Fernando Apesteguía <fernape@FreeBSD.org> AuthorDate: 2023-02-17 10:16:12 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2023-02-18 12:26:40 +0000 lang/execline: Fix permissions for some files Some executables did not have the right permissions. PR: 268593 Reported by: sg@redu.cx lang/execline/Makefile | 1 + lang/execline/pkg-plist | 10 ++++++---- 2 files changed, 7 insertions(+), 4 deletions(-)