GNU bug report logs - #78836
/var/empty permissions problems between sshd and nslcd

Previous Next

To reply to this bug, email your comments to 78836 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yann Dupont <yann.dupont <at> univ-nantes.fr>
To: bug-guix <at> gnu.org
Subject: /var/empty permissions problems between sshd and nslcd
Date: Thu, 19 Jun 2025 09:43:04 +0200

[Message part 1 (text/plain, inline)]

Hi everyone, the patch eab097c682ed31efd8668f46fce8de8f73b92849 causes 
sshd to now use /var/empty as a chroot directory. sshd expects 
/var/empty to belong to root and with reduced write permissions.

Unfortunately, when the nslcd service is also present on the system, it 
creates a user whose home directory is also /var/empty, which in this 
case belongs to the nslcd user.

In this case, sshd refuses to start.

I think the patch eab097c682ed31efd8668f46fce8de8f73b92849 is correct, 
and that nslcd should be changed to create /var/empty with the directory 
property set to root. But I don't know if there are any side effects to 
worry about with nslcd ?

(I think the relevant code is in : services/authentication.scm), in 
(|define %nslcd-accounts)
|

|...|

|(home-directory "/var/empty")|

[Message part 2 (text/html, inline)]

Message #8 received at 78836 <at> debbugs.gnu.org (full text, mbox):

From: Sergey Trofimov <sarg <at> sarg.org.ru>
To: Yann Dupont <yann.dupont <at> univ-nantes.fr>
Cc: 78836 <at> debbugs.gnu.org
Subject: Re: bug#78836: /var/empty permissions problems between sshd and nslcd
Date: Thu, 19 Jun 2025 10:56:28 +0200

Hi Yann,

Yann Dupont <yann.dupont <at> univ-nantes.fr> writes:

> Hi everyone, the patch eab097c682ed31efd8668f46fce8de8f73b92849 causes sshd to now use /var/empty as a chroot directory.
> sshd expects /var/empty to belong to root and with reduced write permissions.
>
> Unfortunately, when the nslcd service is also present on the system, it creates a user whose home directory is also /var/empty, which
> in this case belongs to the nslcd user.
>
> In this case, sshd refuses to start.
>
> I think the patch eab097c682ed31efd8668f46fce8de8f73b92849 is correct, and that nslcd should be changed to create /var/empty
> with the directory property set to root. But I don't know if there are any side effects to worry about with nslcd ?
>
> (I think the relevant code is in : services/authentication.scm), in (define %nslcd-accounts)
>
> ...
>
> (home-directory "/var/empty")

Check activate-users+groups in (gnu build activation). It should've
adjusted directory permissions and ownership on /var/empty. There are
many more accounts having /var/empty as the home dir (e.g. guixbuilder,
guix-daemon accounts). Looks quite suspicious that in your case the dir
belongs to nslcd. Could you try to reconfigure the system and see if the
permissions get fixed?

Message #11 received at 78836 <at> debbugs.gnu.org (full text, mbox):

From: Sergey Trofimov <sarg <at> sarg.org.ru>
To: Yann Dupont <yann.dupont <at> univ-nantes.fr>
Cc: 78836 <at> debbugs.gnu.org
Subject: Re: bug#78836: /var/empty permissions problems between sshd and nslcd
Date: Thu, 19 Jun 2025 13:19:42 +0200

Hi

Yann Dupont <yann.dupont <at> univ-nantes.fr> writes:

> I don't know if this is relevant information, but we encounter this problem on disposable virtual machines, freshly generated by guix
> system image for one-time use, we don't reconfigure on these machines. Maybe this function is not called in this specific case?
>
> I'll see if a reconfigure changes things, , but it's going to take some time, as our templates are a bit complex and divided into
> several files that can't be found in /running/current-system/configuration.scm.

You could simply run /run/current-system/activate and check if it fixes permissions.

Message #14 received at 78836 <at> debbugs.gnu.org (full text, mbox):

From: Yann Dupont <yann.dupont <at> univ-nantes.fr>
To: Sergey Trofimov <sarg <at> sarg.org.ru>
Cc: 78836 <at> debbugs.gnu.org
Subject: Re: bug#78836: /var/empty permissions problems between sshd and nslcd
Date: Fri, 20 Jun 2025 15:17:08 +0200

On 19/06/2025 13:19, Sergey Trofimov wrote:
> Hi
>
> Yann Dupont <yann.dupont <at> univ-nantes.fr> writes:
>
>> I don't know if this is relevant information, but we encounter this problem on disposable virtual machines, freshly generated by guix
>> system image for one-time use, we don't reconfigure on these machines. Maybe this function is not called in this specific case?
>>
>> I'll see if a reconfigure changes things, , but it's going to take some time, as our templates are a bit complex and divided into
>> several files that can't be found in /running/current-system/configuration.scm.
> You could simply run /run/current-system/activate and check if it fixes permissions.
Hi Sergey, launching /run/current-system/activate does not change the 
directory property.

However, I'm afraid this could be a problem on our side. By simplifying 
a vm definition as much as possible to be able to reproduce, the nslcd 
service creates /var/empty with root as owner... so something unexpected 
is happening on our side. I'll look into it.

Thanks for your help,

-- 
Yann Dupont - GLiCID / HPC Pays de la Loire
Tel : 02.53.48.49.39 - Yann.Dupont <at> univ-nantes.fr

Message #17 received at 78836 <at> debbugs.gnu.org (full text, mbox):

From: Sergey Trofimov <sarg <at> sarg.org.ru>
To: Yann Dupont <yann.dupont <at> univ-nantes.fr>
Cc: 78836 <at> debbugs.gnu.org
Subject: Re: bug#78836: /var/empty permissions problems between sshd and nslcd
Date: Fri, 20 Jun 2025 17:57:55 +0200

Hi Yann, 

Yann Dupont <yann.dupont <at> univ-nantes.fr> writes:

> On 19/06/2025 13:19, Sergey Trofimov wrote:
>> Hi
>>
>> Yann Dupont <yann.dupont <at> univ-nantes.fr> writes:
>>
>>> I don't know if this is relevant information, but we encounter this problem on disposable virtual machines, freshly generated by guix
>>> system image for one-time use, we don't reconfigure on these machines. Maybe this function is not called in this specific case?
>>>
>>> I'll see if a reconfigure changes things, , but it's going to take some time, as our templates are a bit complex and divided into
>>> several files that can't be found in /running/current-system/configuration.scm.
>> You could simply run /run/current-system/activate and check if it fixes permissions.
> Hi Sergey, launching /run/current-system/activate does not change the directory
> property.
>
> However, I'm afraid this could be a problem on our side. By simplifying a vm
> definition as much as possible to be able to reproduce, the nslcd service
> creates /var/empty with root as owner... so something unexpected is happening on
> our side. I'll look into it.
>
> Thanks for your help,

If the OS is stripped to the bare minimum, I assume that it doesn't have
all the system users usually present in Guix system (daemon and
builders). It could happen that nslcd is the only user with the home dir
set to /var/empty (check /etc/passwd). In that case
activate-users+groups won't be changing the permissions because it only
does that on directories that are shared between multiple accounts.

Message #20 received at 78836 <at> debbugs.gnu.org (full text, mbox):

From: Yann Dupont <yann.dupont <at> univ-nantes.fr>
To: Sergey Trofimov <sarg <at> sarg.org.ru>
Cc: 78836 <at> debbugs.gnu.org
Subject: Re: bug#78836: /var/empty permissions problems between sshd and nslcd
Date: Fri, 20 Jun 2025 18:08:12 +0200

[Message part 1 (text/plain, inline)]

On 20/06/2025 17:57, Sergey Trofimov wrote:
> If the OS is stripped to the bare minimum, I assume that it doesn't have
> all the system users usually present in Guix system (daemon and
> builders). It could happen that nslcd is the only user with the home dir
> set to /var/empty (check /etc/passwd). In that case
> activate-users+groups won't be changing the permissions because it only
> does that on directories that are shared between multiple accounts.

yes, I was debugging this afternoon and just came to the same conclusion :

The culprit is this line  (modify-services %base-services (delete 
guix-service-type))

We delete it because our store is shared and GUIX_DAEMON_SOCKET set.

I think we can close this bug report, as I imagine there can't be many 
of us with this problem.

Thanks a lot for the explanation,

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.