‘guix pack -f docker’ creates an image without /etc/passwd

  • Open
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 23 Aug 2019 17:00
(address . bug-Guix@gnu.org)
87r25c3p0e.fsf@inria.fr
‘guix pack -f docker’ currently creates an image without
/etc/{passwd,group,shadow}.

It’s OK most of the time, but again it looks like a gratuitous annoyance
for those cases where having them around matters (that’s also the reason
why guix-daemon creates them.)

Unless there are objections, I’d like to create these with just the
“root” and “nobody” accounts. Or should we have a regular unprivileged
account? But then what should its UID be?

Ludo’.
R
R
Ricardo Wurmus wrote on 23 Aug 2019 22:16
Re: bug#37162: ‘guix pack -f docker ’ creates an image without /etc/passwd
(address . 37162@debbugs.gnu.org)(address . ludovic.courtes@inria.fr)
874l27k587.fsf@elephly.net
Ludovic Courtès <ludovic.courtes@inria.fr> writes:

Toggle quote (2 lines)
> ‘guix pack -f docker’ currently creates an image without
> /etc/{passwd,group,shadow}.
[…]
Toggle quote (4 lines)
> Unless there are objections, I’d like to create these with just the
> “root” and “nobody” accounts. Or should we have a regular unprivileged
> account? But then what should its UID be?

Is there perhaps a configuration that we could add to the Docker image
meta-data to have Docker do the right thing? The right thing might be
to map these files from the host into the container automatically, or to
instruct Docker to create them when starting the container.

I would prefer to accomplish this via configuration “hints” if possible
instead of creating dummy files with specific contents.

(I don’t know if this is at all possible.)

--
Ricardo
M
M
Maxim Cournoyer wrote on 25 Aug 2019 23:32
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)(address . bug-Guix@gnu.org)
87a7bxexs6.fsf@gmail.com
Hi Ludovic,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

Toggle quote (7 lines)
> ‘guix pack -f docker’ currently creates an image without
> /etc/{passwd,group,shadow}.
>
> It’s OK most of the time, but again it looks like a gratuitous annoyance
> for those cases where having them around matters (that’s also the reason
> why guix-daemon creates them.)

Would that include the files required for PAM authentication to work
correctly? I remember struggling with this use case: using the Docker
image with CQFD wrapper, which must be able to create a user and
sudo'ing (or 'su') to it in the docker container. I had started
populating base files such as shadow, passwd, etc. but when confronted
with the PAM configuration (which sudo was complaining about), it
appeared intimidating. I then decided to modify my operating system
declaration so that it'd contain the required Shepherd services that
populate /etc, and devise a hack to call
'/var/guix/profiles/system/boot' when the container would start.

The minimal system configuration (+ python stuff, which was the
requirement) I came up with was:

Toggle snippet (68 lines)
;; This is an operating system configuration template for a bare-bone,
;; containerization-friendly setup, with no X11 display server and
;; no Guix daemon / client.

(use-modules (gnu)
(gnu packages bash)
(gnu packages python)
(gnu packages python-xyz)
(gnu packages xml)
(guix packages))

(operating-system
(host-name "robot-framework")
(timezone "America/Montreal")

;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
;; target hard disk, and "my-root" is the label of the target
;; root file system.
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))
(file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))

(users (cons (user-account
(name "builder")
(group "users")
(supplementary-groups '("wheel"))
(home-directory "/home/builder"))
%base-user-accounts))

;; Globally-installed packages.
(packages (cons* python-wrapper
(list python "tk")
python-robotframework
python-robotframework-sshlibrary
python-robotframework-lint
python-xmltodict
%base-packages))

(services (list
;; Enable #!/bin/sh and #!/bin/bash shebangs.
(service special-files-service-type
`(("/bin/bash" ,(file-append (canonical-package bash)
"/bin/bash"))))
(service special-files-service-type
`(("/bin/sh" ,(file-append (canonical-package bash)
"/bin/sh"))))
;; The following is a very small subset extracted of
;; %base-services.
(service login-service-type)
(service udev-service-type (udev-configuration))
(syslog-service)))

;; When using sudo, by default some environment variables such as
;; PYTHONPATH are dropped. Make it so that any environment
;; variables are honored. This is important so that the Guix system
;; profile can work correctly for any user.
(sudoers-file (plain-file "sudoers" "\
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
Defaults !env_reset,!env_delete\n")))


Maxim
R
R
Ricardo Wurmus wrote on 25 Aug 2019 18:28
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
871rx9jjl2.fsf@elephly.net
Hi Maxim,

Toggle quote (14 lines)
> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>
>> ‘guix pack -f docker’ currently creates an image without
>> /etc/{passwd,group,shadow}.
>>
>> It’s OK most of the time, but again it looks like a gratuitous annoyance
>> for those cases where having them around matters (that’s also the reason
>> why guix-daemon creates them.)
>
> Would that include the files required for PAM authentication to work
> correctly? I remember struggling with this use case: using the Docker
> image with CQFD wrapper, which must be able to create a user and
> sudo'ing (or 'su') to it in the docker container.

I wonder if at this point it wouldn’t be better to build a whole system
container. Isn’t that outside the scope of “guix pack” and rather a
task for “guix system”?

--
Ricardo
M
M
Maxim Cournoyer wrote on 26 Aug 2019 11:19
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87y2zge11z.fsf@gmail.com
Hello Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (20 lines)
> Hi Maxim,
>
>> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>>
>>> ‘guix pack -f docker’ currently creates an image without
>>> /etc/{passwd,group,shadow}.
>>>
>>> It’s OK most of the time, but again it looks like a gratuitous annoyance
>>> for those cases where having them around matters (that’s also the reason
>>> why guix-daemon creates them.)
>>
>> Would that include the files required for PAM authentication to work
>> correctly? I remember struggling with this use case: using the Docker
>> image with CQFD wrapper, which must be able to create a user and
>> sudo'ing (or 'su') to it in the docker container.
>
> I wonder if at this point it wouldn’t be better to build a whole system
> container. Isn’t that outside the scope of “guix pack” and rather a
> task for “guix system”?

Probably! But then one has to wonder if adding some base files to `guix
pack' is not one of those slippery slopes where users come back
expecting more stuff to be there?

What use case(s) exactly depend on the presence of the
/etc/{passwd,group,shadow} files?

Maxim
L
L
Ludovic Courtès wrote on 26 Aug 2019 09:37
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87y2zg2x7z.fsf@inria.fr
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (22 lines)
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Maxim,
>>
>>> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>>>
>>>> ‘guix pack -f docker’ currently creates an image without
>>>> /etc/{passwd,group,shadow}.
>>>>
>>>> It’s OK most of the time, but again it looks like a gratuitous annoyance
>>>> for those cases where having them around matters (that’s also the reason
>>>> why guix-daemon creates them.)
>>>
>>> Would that include the files required for PAM authentication to work
>>> correctly? I remember struggling with this use case: using the Docker
>>> image with CQFD wrapper, which must be able to create a user and
>>> sudo'ing (or 'su') to it in the docker container.
>>
>> I wonder if at this point it wouldn’t be better to build a whole system
>> container. Isn’t that outside the scope of “guix pack” and rather a
>> task for “guix system”?

I think so.

Toggle quote (7 lines)
> Probably! But then one has to wonder if adding some base files to `guix
> pack' is not one of those slippery slopes where users come back
> expecting more stuff to be there?
>
> What use case(s) exactly depend on the presence of the
> /etc/{passwd,group,shadow} files?

Generally, absent these files, getpw(3) and co. won’t give useful
results, and some applications will behave poorly (e.g., the PS1 prompt
in Bash can’t show the user name; ‘id’ fails).

Most of the time it’s just a minor inconvenience.

Ludo’.
R
R
Ricardo Wurmus wrote on 26 Aug 2019 13:39
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)
87sgpoi29v.fsf@elephly.net
Ludovic Courtès <ludovic.courtes@inria.fr> writes:

Toggle quote (9 lines)
>> What use case(s) exactly depend on the presence of the
>> /etc/{passwd,group,shadow} files?
>
> Generally, absent these files, getpw(3) and co. won’t give useful
> results, and some applications will behave poorly (e.g., the PS1 prompt
> in Bash can’t show the user name; ‘id’ fails).
>
> Most of the time it’s just a minor inconvenience.

I think it’s fine to add these files to avoid this source of
inconvenience.

Perhaps it would be good to recommend in the manual the use of “guix
system” for those who need more control over the contents of these
files.

And maybe we can make some really simple template system configuration
available to “guix system” without requiring users to fully specify the
operating system configuration. I’m thinking of something like this
where %simple-os is made available by default:

(operating-system
(inherit %simple-os)
(packages (list "a" "b" "c")))

--
Ricardo
M
M
Maxim Cournoyer wrote on 31 Aug 2019 17:02
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)
87k1at5qev.fsf@gmail.com
Hello! Sorry for the late reply.

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

Toggle quote (39 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Hi Maxim,
>>>
>>>> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>>>>
>>>>> ‘guix pack -f docker’ currently creates an image without
>>>>> /etc/{passwd,group,shadow}.
>>>>>
>>>>> It’s OK most of the time, but again it looks like a gratuitous annoyance
>>>>> for those cases where having them around matters (that’s also the reason
>>>>> why guix-daemon creates them.)
>>>>
>>>> Would that include the files required for PAM authentication to work
>>>> correctly? I remember struggling with this use case: using the Docker
>>>> image with CQFD wrapper, which must be able to create a user and
>>>> sudo'ing (or 'su') to it in the docker container.
>>>
>>> I wonder if at this point it wouldn’t be better to build a whole system
>>> container. Isn’t that outside the scope of “guix pack” and rather a
>>> task for “guix system”?
>
> I think so.
>
>> Probably! But then one has to wonder if adding some base files to `guix
>> pack' is not one of those slippery slopes where users come back
>> expecting more stuff to be there?
>>
>> What use case(s) exactly depend on the presence of the
>> /etc/{passwd,group,shadow} files?
>
> Generally, absent these files, getpw(3) and co. won’t give useful
> results, and some applications will behave poorly (e.g., the PS1 prompt
> in Bash can’t show the user name; ‘id’ fails).

I see! I understand better the source of the annoyance now, thanks!

Toggle quote (2 lines)
> Most of the time it’s just a minor inconvenience.

It seems OK to me to add those small files since make the experience
better.

Maxim
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 37162@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 37162
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