This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson3214's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.

This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson3214's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.

This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson3214's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.

This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson2314's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.

This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson2314's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.

This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson2314's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.

This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson2314's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.

This is a minor simplification; there's now slightly less handshaking
required between the builder and the parent, and we create one less pipe
when starting the builder.

As a niche benefit, this also replaces our access to `/proc/builder_pid`
in the parent with an access to `/proc/self` in the builder. The former
access could fail if `/proc` was mounted in a different pid namespace
from the one we are running in; now we will work even if there is such a
misconfiguration.

----

Rebaser's (@Ericson2314's) notes:

A good questions why it was ever done the old way, since this is simpler
and easier to write. The original commit doing this was
c68e591, adding user namespae support
for the first time, and referencing issue NixOS#625. But neither mention this
design decision.

In NixOS#2717 (comment) Eelco
said:

> I don't remember why it's done this way. Maybe the kernel required it
> at the time?

That seems to me like a likely explanation. User namespaces were
famously fiddly for many years.