Some beginner questions...

[Ben Cooksley]

On Sun, Mar 6, 2022 at 8:01 AM Alexander Neundorf <neundorf at kde.org> wrote:

> On Samstag, 5. März 2022 19:11:53 CET Ben Cooksley wrote:
> > On Sun, Mar 6, 2022 at 6:17 AM Alexander Neundorf <neundorf at kde.org>
> wrote:
> > > On Sonntag, 21. November 2021 21:38:14 CET Albert Astals Cid wrote:
> > > > El diumenge, 21 de novembre de 2021, a les 18:20:08 (CET), Alexander
> > >
> > > Neundorf va escriure:
> > > ...
> > >
> > > > > Is there a reason why less, vi and mc are not part of the image ?
> > > > > They make working in the container much nicer :-)
> > > >
> > > > You can always
> > > >
> > > >   sudo apt install vim
> > > >
> > > > no?
> > >
> > > I get errors:
> > > I have no name!@8fdf0c048ce2:~$ sudo apt-get install vim
> > > sudo: you do not exist in the passwd database
> > > I have no name!@8fdf0c048ce2:~$
> >
> > If you'd like to be root then something like this should work:
> >
> > docker exec -u root $containerId /bin/bash
> >
> > Bit unusual that you have managed to get a shell as a user account that
> > does not exist, by default both our SUSE CI images and the Android CI
> image
> > should run shells as root.
> > The Android SDK image should spawn a shell as 'user' (UID 1000)
>
> I mounted my host users src-directory into the container, so I need to
> have
> the same user- and group-ids in the container as on the host.
> If I run as root in the container, I am also root on the directory which I
> mounted into the container, so if I touch something in the container, it's
> owned by root, also on the host.
> Using the same user ID in the container as on the host makes that work
> smoothly (but then I'm not root and cannot install anything).
> Then I can simply edit on the host using kate or whatever, and build in
> the
> container, and nothing is lost, neither sources nor build results.
>

I see. In this case I would suggest creating (via a root terminal) a
matching user account/group in the container before beginning usage of it.

The normal 'user' account in the container is created with UID 1000 I
believe which for the vast majority of people should match their host
system.


>
> Maybe during container startup the /etc/sudoers could be patched so that
> it
> allows the user who is running it can do sudo...
>

We don't allow sudo because permitting that would allow attacks against the
CI system physical hosts.


>
> > > When mounting /etc/passwd into the container I get the following:
> > >
> > > alex at 792716dfb133:~$ sudo apt-get install vim
> > > [sudo] password for alex:
> > > Sorry, try again.
> > > [sudo] password for alex:
> > > Sorry, try again.
> > > [sudo] password for alex:
> > > sudo: 3 incorrect password attempts
> >
> > You will need to mount /etc/shadow in as well for your password to come
> > through.
> > I wouldn't recommend mounting either file into the container though.
>
> They are mounted read-only, I'm using that since years for other purposes
> without problems. What issues do you see ?
>

If your distribution and the container distribution are different, then
certain files within the container will no longer be owned by the
appropriate system accounts.
It sounds like you are mixing Ubuntu and SUSE which will definitely trigger
this.

This may lead to setuid binaries (not owned by root) not behaving correctly
- and may also impact post-install processes if you are installing software
in the container.


>
>
> Alex
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20220306/90dfabc1/attachment.htm>