On 14/11/2025 13:43, Ralph Ronnquist wrote:
> On Fri, Nov 14, 2025 at 12:57:51PM +1100, wirelessduck@??? wrote:
>>
>>
>>> On 13 Nov 2025, at 21:31, Simon Josefsson <simon@???> wrote:
>>>
>>> Hi
>>>
>>> Thanks for excalibur and container images! I enabled use of them in a
>>> GitLab build pipeline, but got an error installing openssh-client:
>>>
>>> https://gitlab.com/libidn/libidn2/-/jobs/12074318631
>>>
>>> Any ideas? Some permission diff between devuan6 vs debian13 containers?
>>>
>>> Setting up openssh-client (1:10.0p1-7) ...
>>> Insecure directory in $ENV{PATH} while running with -T switch at /usr/share/perl5/Debian/AdduserLogging.pm line 161.
>>> dpkg: error processing package openssh-client (--configure):
>>> installed openssh-client package post-installation script subprocess returned error exit status 25
>>> ...
>>> Errors were encountered while processing:
>>> openssh-client
>>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>>>
>>> Running the exact same commands in a debian13 container works on the
>>> same runner, so I think this is a devuan-specific problem. Here is the
>>> debian13 log for comparison:
>>>
>>> https://gitlab.com/libidn/libidn2/-/jobs/12074318651
>>>
>>> /Simon
>>
>> Hi Simon,
>>
>> This is a known issue. I haven’t yet found the cause of the incorrect permissions.
>>
>> https://git.devuan.org/paddy-hack/container-images/issues/67
>
> In some cases the reason seems quite convoluted. For me it seemed to
> be due to the adduser perl script using the -T option, which enables
> additional security for perl script interpretation. In particular it
> prohibits the script using a system call that relies on the external
> PATH setting (i.e. a simple command in a system call).
>
> Here it's an adduser script bug; simply that the script makes a log
> call before it sets PATH. That log call includes a simple system call
> which thus ends up using the external PATH setting rather than
> adduser's PATH that gets set later.
>
> I'm not sure there is a way to avoid that bug short of editing the
> adduser script.
>
> Ralph.

A similar problem I can’t yet identify the cause of, in addition to the
wrong permissions of /usr/sbin, is in my comment on the linked issue
[1]. If we can identify and fix what is causing the incorrect directory
permissions, then the taint mode (-T) will not be a problem.

Comment copied here below...

I can see that all devuan images back to beowulf appear to have usrmerge
symlinks present for /bin, /sbin, /lib, /lib32, /lib64, /libx64. The
debian images only have usrmerge symlinks starting from bookworm.

All devuan images back to ascii have chmod 0777 for /etc and /usr. I
can't see this in any of the debian images.

$ docker run --rm -it devuan/devuan:beowulf /bin/bash
Unable to find image 'devuan/devuan:beowulf' locally
beowulf: Pulling from devuan/devuan
4396b968ae7d: Pull complete
Digest: 
sha256:cfcb7be09e4580fe8611b655c11ce6ce9c0ccf80dbb48e3edf3397f2911edb44
Status: Downloaded newer image for devuan/devuan:beowulf
root@d5392f2ae695:/# ls -l --color=auto
total 48
lrwxrwxrwx   1 root root    7 Jun 30  2024 bin -> usr/bin
drwxr-xr-x   2 root root 4096 Jun  3  2020 boot
drwxr-xr-x   5 root root  360 Nov  9 23:29 dev
drwxrwxrwx   1 root root 4096 Nov  9 23:29 etc
drwxr-xr-x   2 root root 4096 Jun  3  2020 home
lrwxrwxrwx   1 root root    7 Jun 30  2024 lib -> usr/lib
lrwxrwxrwx   1 root root    9 Jun 30  2024 lib32 -> usr/lib32
lrwxrwxrwx   1 root root    9 Jun 30  2024 lib64 -> usr/lib64
lrwxrwxrwx   1 root root   10 Jun 30  2024 libx32 -> usr/libx32
drwxr-xr-x   2 root root 4096 Jun 30  2024 media
drwxr-xr-x   2 root root 4096 Jun 30  2024 mnt
drwxr-xr-x   2 root root 4096 Jun 30  2024 opt
dr-xr-xr-x 327 root root    0 Nov  9 23:29 proc
drwx------   2 root root 4096 Jun 30  2024 root
drwxr-xr-x   2 root root 4096 Jun 30  2024 run
lrwxrwxrwx   1 root root    8 Jun 30  2024 sbin -> usr/sbin
drwxr-xr-x   2 root root 4096 Jun 30  2024 srv
dr-xr-xr-x  13 root root    0 Nov  9 11:33 sys
drwxrwxrwt   2 root root 4096 Jun 30  2024 tmp
drwxrwxrwx  13 root root 4096 Jun 15  2024 usr
drwxr-xr-x  11 root root 4096 Jun 30  2024 var

$ docker run --rm -it devuan/devuan:ascii /bin/bash
Unable to find image 'devuan/devuan:ascii' locally
ascii: Pulling from devuan/devuan
8024bc919ca8: Pull complete
Digest: 
sha256:a32f6c15cb8f4c5bf0aa9686f807a69b3e9bdefad4a77090f0103b0316517f51
Status: Downloaded newer image for devuan/devuan:ascii
root@d42253bafe87:/# ls -l --color=auto
total 64
drwxr-xr-x   2 root root 4096 Dec 25  2022 bin
drwxr-xr-x   2 root root 4096 Feb 23  2020 boot
drwxr-xr-x   5 root root  360 Nov  9 23:30 dev
drwxrwxrwx   1 root root 4096 Nov  9 23:30 etc
drwxr-xr-x   2 root root 4096 Feb 23  2020 home
drwxr-xr-x   9 root root 4096 Dec 25  2022 lib
drwxr-xr-x   2 root root 4096 Dec 25  2022 lib64
drwxr-xr-x   2 root root 4096 Dec 25  2022 media
drwxr-xr-x   2 root root 4096 Dec 25  2022 mnt
drwxr-xr-x   2 root root 4096 Dec 25  2022 opt
dr-xr-xr-x 369 root root    0 Nov  9 23:30 proc
drwx------   2 root root 4096 Dec 25  2022 root
drwxr-xr-x   2 root root 4096 Dec 25  2022 run
drwxr-xr-x   2 root root 4096 Dec 25  2022 sbin
drwxr-xr-x   2 root root 4096 Dec 25  2022 srv
dr-xr-xr-x  13 root root    0 Nov  9 11:33 sys
drwxrwxrwt   2 root root 4096 Dec 25  2022 tmp
drwxrwxrwx  10 root root 4096 Dec 22  2022 usr
drwxr-xr-x  11 root root 4096 Dec 25  2022 var

Tom

[1]
https://git.devuan.org/paddy-hack/container-images/issues/67#issuecomment-4267