[Bug]: perhaps SNAPCRAFT_MANAGED_MODE=n should be set

[jocado]

What happened?

Hi @diddledani

This is probably more of a discussion point, than a bug, as such. The answer may be that the current setting is the most correct after all.

First of all , full disclaimer, I am having to use a forked version of this repo. This is due to some internal reasons that wouldn't make sense to try and accommodate in this project directly. But I'm keeping it in sync as much as is practical. As it's a fork, we have also added the possibility to run snapcraft as non root user, because we are using the docker image to run locally sometimes as well as in CI, and on your own local host it's more secure and practical to use non root. [ Actually, I guess the non-root feature could be up-streamed if it was useful :) ]

The problem

It seems that for core22 snaps, setting SNAPCRAFT_MANAGED_MODE=y has some subtly different effects than < core22. The problem I found is that it seems to enforce setting /root as the home path, which doesn't work well when the users is not root.

https://github.com/snapcore/snapcraft/blob/main/snapcraft/utils.py#L167-L169

https://github.com/snapcore/snapcraft/blob/main/snapcraft/parts/lifecycle.py#L664-L667

I can of course simply change this for non-root users only in our fork, by setting SNAPCRAFT_MANAGED_MODE=n in that case. However, there are other benefits in CI environments of not using /root for the rest of the project components, ans so am wondering if change to SNAPCRAFT_MANAGED_MODE=n wholesale for every scenario makes more sense.

Also worth noting we are running with --destructive-mode

Any thoughts ? Is setting SNAPCRAFT_MANAGED_MODE=y needed for any other reason ?

What should have happened?

perhaps SNAPCRAFT_MANAGED_MODE=n should be set ?

Output of snap info $snap_name

n/a

Output of snap connections $snap_name

n/a

Output of snap version

n/a

Relevant log output

No response

Teminal output of app

No response

[lucyllewy]

I'm not sure why you're running with --destructive-mode when using this image as the container is already set up to do the equivalent via alternative means that are better supported by upstream Snapcraft.

I'd like to see how you're getting around the requirements of systemd inside a container when running as non-root, as the usage of systemd is a design goal of this image, and cannot be run as non-root. It also requires privileged mode via Docker or the systemd support from podman (podman is minimally tested and likely doesn't work, and last I recall required running through sudo on your host to gain access to filesystem mounting support)

[jocado]

I'm not sure why you're running with --destructive-mode

I have just been digging into this, and I have to admit, using --destructive-mode does seem somewhat pointless in this case. I think this may be due miss-understanding and hangover from how we were originally running snapcraft. It looks like that can be removed 👍

I'd like to see how you're getting around the requirements of systemd inside a container when running as non-root

I haven't fully explained the scenario. We're not running without any root user at all, as you say it wouldn't be possible to run systemd as non-root.

We have configured the docker-exec.service to run as an operationally specified user/group when invoking the container.

When not running in CI, and being run locally on an end users device, this helps make file permissions in the home directory easier to work with [ they don't end up with files owned as root there ]. It also enhances the security slightly and avoids the potential of unhappy accidents, as they can pass in any commands to run etc.

When running in CI, it always runs as root on ephemeral infrastructure, with a very specific command set, and there are no issues around file permissions etc.

Our systemd Service definition looks like this:

[Service]
User=$SNAP_USER
Group=$SNAP_USER
ExecStartPre=+/bin/bash -c '/usr/bin/snap install /snapd.snap --dangerous < /dev/null'
ExecStartPre=+/bin/bash -c '/usr/bin/snap install snapcraft --classic --channel $USE_SNAPCRAFT_CHANNEL < /dev/null'
ExecStart=/usr/local/bin/docker_commandline.sh
Environment="SNAPPY_LAUNCHER_INSIDE_TESTS=true"
Environment="LANG=C.UTF-8"
Restart=no
Type=oneshot
StandardInput=tty
StandardOutput=tty
StandardError=tty
WorkingDirectory=$PWD

Slight caveat, that get's modified to sudo instead of + for core base, as the systemd version used there doesn't support + syntax.

The reason we want to sue this locally, as well as in CI, is makes the build env consistent in all cases, when locally hacking/testing and building and publishing for production.

Hope that explanation makes some sense.

Back the original question, should SNAPCRAFT_MANAGED_MODE=n be set by default ?

Like I said , it's more a discussion point. Perhaps the answer is no, but I was interested to get your PoV 🙂

The primary reason to change it from our perspective it so prevent enforcing /root as the home and project dir. Relavent code seems to be here: https://github.com/snapcore/snapcraft/blob/main/snapcraft/parts/lifecycle.py#L259-L263

This fundamentally breaks the process when running as non-root. This only seems to be an issue using the non-legacy snapcraft code, so with building core22 base snaps.

So I guess my question would be, what is the reason to set SNAPCRAFT_MANAGED_MODE=y when using these images. Is there something it's adding that I'm missing ? If there is something I'm missing, then I wouldn't did it in our fork either, and I would investigate finding another way to solve our specific issues 👍

Thanks!

[jocado]

One other issue that I just found which may be useful to consider.

It seems like when using SNAPCRAFT_MANAGED_MODE=y and core22, gadget snaps fail to compile. Using SNAPCRAFT_MANAGED_MODE=n makes them work again.

snapcraft fails with this error:

gadget.yaml is required for gadget snaps

For instance, the reference pc-gadget, 22 branch: https://github.com/snapcore/pc-gadget/tree/22

docker run --rm -it --privileged -v $PWD:/data -w /data diddledani/snapcraft:core22 snapcraft --verbosity debug
~~~8<~~~
2023-02-24 19:48:23.642 Executed: build grub                                                                                                                               
2023-02-24 19:48:23.642 Executing parts lifecycle: stage grub                                                                                                              
2023-02-24 19:48:23.642 Executing action                                                                                                                                   
2023-02-24 19:48:23.642 execute action grub:Action(part_name='grub', step=Step.STAGE, action_type=ActionType.RUN, reason=None, project_vars=None)                          
2023-02-24 19:48:23.662 Executed: stage grub                                                                                                                               
2023-02-24 19:48:23.662 Executing parts lifecycle: prime grub                                                                                                              
2023-02-24 19:48:23.662 Executing action                                                                                                                                   
2023-02-24 19:48:23.662 execute action grub:Action(part_name='grub', step=Step.PRIME, action_type=ActionType.RUN, reason=None, project_vars=None)                          
2023-02-24 19:48:23.682 Executed: prime grub                                                                                                                               
2023-02-24 19:48:23.682 Executed parts lifecycle                                                                                                                           
2023-02-24 19:48:23.682 Extracting and updating metadata...                                                                                                                
2023-02-24 19:48:23.683 Copying snap assets...                                                                                                                             
2023-02-24 19:48:23.684 gadget.yaml is required for gadget snaps                                                                                                           
2023-02-24 19:48:23.685 Traceback (most recent call last):                                                                                                                 
2023-02-24 19:48:23.685   File "/snap/snapcraft/8619/lib/python3.8/site-packages/snapcraft/parts/lifecycle.py", line 284, in _run_command                                  
2023-02-24 19:48:23.685     _run_lifecycle_and_pack(                                                                                                                       
2023-02-24 19:48:23.685   File "/snap/snapcraft/8619/lib/python3.8/site-packages/snapcraft/parts/lifecycle.py", line 337, in _run_lifecycle_and_pack                       
2023-02-24 19:48:23.686     _generate_metadata(                                                                                                                            
2023-02-24 19:48:23.686   File "/snap/snapcraft/8619/lib/python3.8/site-packages/snapcraft/parts/lifecycle.py", line 387, in _generate_metadata                            
2023-02-24 19:48:23.686     setup_assets(                                                                                                                                  
2023-02-24 19:48:23.686   File "/snap/snapcraft/8619/lib/python3.8/site-packages/snapcraft/parts/setup_assets.py", line 67, in setup_assets                                
2023-02-24 19:48:23.686     raise errors.SnapcraftError("gadget.yaml is required for gadget snaps")                                                                        
2023-02-24 19:48:23.686 snapcraft.errors.SnapcraftError: gadget.yaml is required for gadget snaps

I believe this is somehow related to the fact that snap assets are copied to the users home directory, but some non-part elements do not seem copied, such as gadget.yaml, which is not in a part location or in the snap dir. gadget.yaml seems to be somewhat special in that regard.

For comparison I did try using the snapcraft snap with the multipass provider, and the 22 branch of the pc-gadget snap seemed to compile fine.