Hi,

Ralph Ronnquist <rrq@???> writes:

> 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.

The change in perl's -T option usage may have caused a number of issues,
but that is not the root cause of the permission issue in the Devuan
Docker container images. It merely exposed a long-standing oversight in
permissions on files added to the chroot that debootstrap builds.

So for the container images I need to fix that. Any fall-out from the
-T option should still be addressed in those packages that have them but
make sure that whatever issue you see is reproducible *outside* a
container image before submitting a bug report.

Thanks,
--
Olaf Meeuwissen