/var/empty permissions problems between sshd and nslcd

  • Open
  • quality assurance status badge
Details
3 participants
  • Sergey Trofimov
  • Yann Dupont
  • Simon Tournier
Owner
unassigned
Submitted by
Yann Dupont
Severity
normal

Debbugs page

Y
Y
Yann Dupont wrote on 19 Jun 00:43 -0700
(address . bug-guix@gnu.org)
b5a0d45a-b589-46b3-89c9-8387adba740d@univ-nantes.fr
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")|
Attachment: file
S
S
Sergey Trofimov wrote on 19 Jun 01:56 -0700
(name . Yann Dupont)(address . yann.dupont@univ-nantes.fr)(address . 78836@debbugs.gnu.org)
877c18xg77.fsf@sarg.org.ru
Hi Yann,

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

Toggle quote (17 lines)
> 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?
S
S
Sergey Trofimov wrote on 19 Jun 04:19 -0700
(name . Yann Dupont)(address . yann.dupont@univ-nantes.fr)(address . 78836@debbugs.gnu.org)
871prgx9kh.fsf@sarg.org.ru
Hi

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

Toggle quote (6 lines)
> 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.
Y
Y
Yann Dupont wrote on 20 Jun 06:17 -0700
(name . Sergey Trofimov)(address . sarg@sarg.org.ru)(address . 78836@debbugs.gnu.org)
b284050c-c541-4089-9598-d96371a6d0ae@univ-nantes.fr
On 19/06/2025 13:19, Sergey Trofimov wrote:
Toggle quote (10 lines)
> Hi
>
> Yann Dupont <yann.dupont@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@univ-nantes.fr
S
S
Sergey Trofimov wrote on 20 Jun 08:57 -0700
(name . Yann Dupont)(address . yann.dupont@univ-nantes.fr)(address . 78836@debbugs.gnu.org)
87ikkqiews.fsf@sarg.org.ru
Hi Yann,

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

Toggle quote (21 lines)
> On 19/06/2025 13:19, Sergey Trofimov wrote:
>> Hi
>>
>> Yann Dupont <yann.dupont@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.
Y
Y
Yann Dupont wrote on 20 Jun 09:08 -0700
(name . Sergey Trofimov)(address . sarg@sarg.org.ru)(address . 78836@debbugs.gnu.org)
cb61344c-bb9c-402c-9616-60872498e2ee@univ-nantes.fr
On 20/06/2025 17:57, Sergey Trofimov wrote:
Toggle quote (7 lines)
> 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,
Attachment: file
S
S
Simon Tournier wrote on 20 Aug 08:44 -0700
87v7mim20u.fsf@gmail.com
Hi,

On Thu, 19 Jun 2025 at 09:43, Yann Dupont <yann.dupont@univ-nantes.fr> wrote:

Toggle quote (23 lines)
> 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")|

What is the status of this report? What is missing for closing or move
forward?

Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 78836@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 78836
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch