16:35:25 <dustymabe> #startmeeting fedora_coreos_meeting
16:35:25 <zodbot> Meeting started Wed Nov  9 16:35:25 2022 UTC.
16:35:25 <zodbot> This meeting is logged and archived in a public location.
16:35:25 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:35:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:35:25 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:35:29 <dustymabe> #topic roll call
16:35:32 <dustymabe> .hi
16:35:33 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:35:41 <spresti[m]> .hello spresti
16:35:41 <zodbot> spresti[m]: spresti 'Steven Presti' <spresti@redhat.com>
16:35:48 <gursewak_> .hi
16:35:49 <zodbot> gursewak_: Sorry, but user 'gursewak_' does not exist
16:35:58 <gursewak> .hi
16:35:59 <zodbot> gursewak: gursewak 'Gursewak Singh' <gurssing@redhat.com>
16:36:01 <ravanelli> .hi
16:36:02 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:36:13 <dustymabe> #hciar spresti[m] gursewak ravanelli
16:36:17 <marmijo> .hi
16:36:17 <zodbot> marmijo: marmijo 'Michael Armijo' <marmijo@redhat.com>
16:36:54 <dustymabe> #chair spresti[m] gursewak ravanelli
16:36:54 <zodbot> Current chairs: dustymabe gursewak ravanelli spresti[m]
16:37:03 <dustymabe> #chair marmijo
16:37:03 <zodbot> Current chairs: dustymabe gursewak marmijo ravanelli spresti[m]
16:37:15 <jlebon> .hello2
16:37:16 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:37:50 <dustymabe> #chair jlebon
16:37:50 <zodbot> Current chairs: dustymabe gursewak jlebon marmijo ravanelli spresti[m]
16:38:37 <dustymabe> sorry for the 5 minute late start today
16:38:40 <dustymabe> #topic Action items from last meeting
16:38:48 <dustymabe> #info there were no action items assigned last meeting!
16:39:00 <spresti[m]> No worries, I was running behind as well
16:39:31 <dustymabe> #topic moby-engine (docker) maintenance in Fedora in question
16:39:36 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1291
16:40:15 <travier> .hi siosm
16:40:17 <zodbot> travier: Sorry, but user 'travier' does not exist
16:40:22 <travier> .hello siosm
16:40:23 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:40:26 <dustymabe> looks like according to bgilbert the clock is running out on moby-engine
16:40:54 <travier> Maybe we need to nudge one the current sub maintainer to pick it up as primary one?
16:41:19 <dustymabe> gotmax: do you have any knowledge of anyone planning to pick it up?
16:42:26 <travier> @copperi[m] @gotmax could one of you two pick it up so that it does not get orphaned?
16:42:42 <dustymabe> s/orphaned/retired/
16:42:46 <travier> This does not bind you in blood for updates
16:42:51 <travier> retired indeed*
16:43:07 <dustymabe> travier: well, it is a commitment of sorts
16:43:08 <travier> it just avoids doing even more paperwork
16:43:30 <dustymabe> i think they've known about it this whole time so if they wanted to pick it up they probably would have already
16:43:34 <travier> Well, I'd say that they are already admin of it so they're already a bit commited
16:44:06 <dustymabe> eh, sometimes admin is gifted to you so you can solve problems because you know how, but don't intend to maintain the package
16:44:42 <travier> yep
16:44:45 <travier> well...
16:44:55 <dustymabe> I can only speak for myself on this topic: I don't really have the cycles to pick up maintaining it. Don't know if anyone else from the community does or not.
16:45:22 <dustymabe> Obviously it would make sense for the maintainer to be someone who uses moby-engine(docker) heavily (scratch your own itch)
16:46:43 <dustymabe> ok we'll see what happens if anyone picks it up.
16:46:58 <jlebon> when's the auto-retire kicking in?
16:47:03 <dustymabe> if no one does then we'll have to figure out what our users are going to do for f37->f38 transition
16:47:33 <dustymabe> jlebon: i'm not sure what the policy is there, but I know it's not forevery
16:47:37 <dustymabe> like 6 weeks or something I think
16:48:01 <dustymabe> Orphan packages will be retired if they remain orphaned for six weeks.
16:48:04 <dustymabe> https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/
16:48:24 <dustymabe> wow - I was mostly guessing there, but was spot on
16:48:31 <jlebon> heh nice
16:48:42 <jlebon> huh, I guess most fedora users use podman?
16:49:05 <dustymabe> ehh, I'm not 100% sure on that
16:49:10 <jlebon> well, a thing could have lots of users but doesn't translate to people wanting maintainership
16:49:10 <dustymabe> this problem hasn't really hit users yet :)
16:49:12 <travier> or install docker from the "official" repos maybe
16:49:51 <travier> https://docs.docker.com/engine/install/fedora/
16:49:54 <jlebon> this is where pinger would've been cool, to see the proportion of runtime usage
16:50:21 <dustymabe> yeah - should we send a message to our devel list and maybe fedora devel?
16:50:46 <jlebon> hmm, if it gets retired i guess we could document how to install the upstream packages?
16:50:57 <jlebon> dustymabe: yeah that sounds reasonable
16:51:17 <dustymabe> jlebon: yeah, but then we'd also need to test that often to make sure it continues to work
16:51:26 <jlebon> oh definitely
16:51:29 <dustymabe> and we'd have no control over the source repo
16:51:47 <dustymabe> i.e. we couldn't freeze on an older version if we needed to
16:52:07 <jlebon> it's of course not ideal, just a possible solution
16:52:11 <dustymabe> yep
16:52:24 <travier> Hopefully the repos have all the versions?
16:52:28 <travier> I'll have to look
16:52:38 <travier> We would ship containerd still right?
16:52:43 <dustymabe> anyone want to volunteer to send an email to the list (and cc fedora devel list)?"
16:52:52 <dustymabe> travier: right, containerd maintainership got picked up IIUC
16:52:59 <jlebon> travier: seems like it: https://download.docker.com/linux/fedora/37/x86_64/stable/Packages/
16:53:29 <travier> then we "just" need to write docs, announcements, etc...
16:53:33 <travier> I can see the headlines coming
16:53:38 <travier> feel*
16:53:49 <dustymabe> i definitely don't like it :(
16:54:09 <travier> OK, I'll start a draft email for devel and will share it before sending
16:54:16 <jlebon> travier++
16:54:16 <zodbot> jlebon: Karma for siosm changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:22 <dustymabe> thanks travier! hackmd would be great
16:54:25 <dustymabe> travier++
16:54:25 <zodbot> dustymabe: Karma for siosm changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:45 <travier> 🍪
16:54:47 <jlebon> #chair travier
16:54:47 <zodbot> Current chairs: dustymabe gursewak jlebon marmijo ravanelli spresti[m] travier
16:55:32 <dustymabe> #action travier will send an email to coreos devel list and cc fedora devel to try to find volunteers to help with moby-engine maintainership in Fedora
16:55:42 <dustymabe> #topic including audit in Fedora CoreOS
16:55:50 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/461
16:56:09 <dustymabe> travier: I think this one was you
16:56:27 <travier> oh yes
16:56:46 <travier> we're in a better place to add audit now but we're still missing a split or something
16:57:08 <travier> we also need to remake the ticket into a proper new package request to answer all questions
16:57:43 <dustymabe> travier: can you catch me up? what changed recently that made this more achievable?
16:57:57 <travier> It's a good first task to do so I may pass that to someone else
16:58:29 <travier> the dependency on initscripts has finally been dropped
16:58:41 <travier> it's now pulling only the service binary
16:58:46 <dustymabe> ok great
16:58:51 <travier> which is still bad but less so
16:58:57 <travier> much smaller
16:59:16 <travier> the remaining step is to split out all the python stuff
17:00:12 <travier> We/I'll have to re-do the new package request, but do we have any objection in general regarding adding this package?
17:00:22 <travier> So that I don't start something for nothing
17:00:31 <travier> it's in RHCOS already AFAIK
17:00:47 <dustymabe> I don't. I've kind of wanted it from the beginning.
17:00:53 <travier> (and in all other Fedora Editions)
17:01:22 <dustymabe> obviously dropping the python deps (if they still exist) is a pre-requisite
17:01:30 <travier> 👍
17:01:42 <dustymabe> any others have opposition to audit in general?
17:02:03 <spresti[m]> Nope.
17:02:18 <jlebon> hmm, i'm not seeing python listed at least in https://koji.fedoraproject.org/koji/rpminfo?rpmID=31832455 or https://koji.fedoraproject.org/koji/rpminfo?rpmID=31832456
17:02:34 <jlebon> so it's possible that's fixed already
17:03:05 <jlebon> shipping `service` is a bit awkward, but not sure it's worth blocking on it
17:03:23 <travier> agree it's not great but it's really small
17:03:37 <dustymabe> #info we think we're in a better position to include auditd in FCOS now, though there is still some work remaining. travier will enumerate the remaining work and look to find volunteers.
17:03:44 <dustymabe> is that accurate ^^?
17:04:04 <jlebon> if it's only used to stop the service, then I wonder if it could be replaced by a dedicated e.g. `auditd-stop` binary instead
17:04:18 <jlebon> shipping `service` makes it easy to use for other purposes
17:04:43 <travier> accurate
17:05:01 <travier> jlebon: yes, the better option that was suggested in the BZ too is to do that
17:05:11 <travier> but no one did the work so fart
17:05:13 <travier> far*
17:05:56 <dustymabe> anything else to discuss on this topic?
17:05:59 <jlebon> my only concern is introducing `service` as a host API
17:06:33 <travier> We can task the "volunteer" on writing a bit of C for that :)
17:06:44 <jlebon> i'm not sure if there's a way to signal that clearly. move it outside of PATH and ship a tiny wrapper `auditd-stop` script that calls it?
17:06:59 <dustymabe> jlebon: I guess we could do some postprocessing
17:07:43 <jlebon> right yeah, i mean just doing it ourselves if we can't reach something at the packaging level
17:07:43 <dustymabe> i.e. mv service auditd-service-stop and then find/replace where it gets called (assuming it's in bash)
17:08:09 <travier> There's already an auditctl command so maybe it could be directly added to that
17:09:09 <travier> I think the "use case" is `service stop auditd`
17:09:13 <travier> or restart
17:09:19 <travier> so service should be the entrypoint
17:09:24 <travier> "should"
17:09:58 <dustymabe> we could modify `service` to not accept a 2nd argument
17:10:09 <dustymabe> or require the second argument be `auditd`
17:10:15 <travier> yes
17:10:18 <dustymabe> then we wouldn't be introducing new host level API
17:10:22 <dustymabe> for other uses
17:10:35 <dustymabe> anyways lots of options here
17:10:43 <dustymabe> anything else before we move to open floor?
17:10:46 <jlebon> man, that bugzilla has a lot of history
17:10:47 <dustymabe> thanks for bringing this up travier
17:11:05 <jlebon> i think we need someone to do an investigation and see what the best path forward is re. `service`
17:12:21 <dustymabe> jlebon: are you advocating for continuing the discussion here or are you OK with moving to open floor?
17:12:31 <jlebon> OK moving to open floor
17:12:36 <dustymabe> #topic open floor
17:12:38 <dustymabe> :)
17:12:42 <jlebon> +1 :)
17:13:16 <dustymabe> #info We are hoping that the F37 release will happen next week. Please test out the `next` stream today and report issues as that will be coming to `testing` very soon.
17:14:07 <fifofonix> i have a question for open floor.  why is core 1000 and is that a good choice?
17:14:25 <fifofonix> is that an appropriate question for here (and now).
17:14:30 <dustymabe> fifofonix: i.e. the UID of the `core` user?
17:15:01 <fifofonix> yes, it occurred to me that 'core' is defaulted with sudo privileges.  and a lot of non-root containers use 1000.  like keycloak.
17:15:42 <fifofonix> if the objective of non-root containers is to limit the breakout potential.  wouldn't it be better to be breaking out into an os id that is not sudo.
17:16:14 <fifofonix> (this is probably a really dumb question)
17:16:28 <dustymabe> no dumb questions, it's a good question
17:17:12 <travier> definitely not a dumb question
17:17:29 <dustymabe> I don't know the exact history of why 1000 was chosen for core (though on a fedora desktop my UID is 1001, so close?)
17:17:45 <jlebon> i don't *think* we hardcode 1000. it's just the first available UID
17:17:48 <travier> you might want to look at using user namespace so that the UID picked inside the container does not matter much
17:17:59 <dustymabe> I will say that I often put my workloads (containers) running as rootless under a secondary (non-core) user that doesn't have sudo access
17:18:43 <dustymabe> travier: rightg
17:18:46 <dustymabe> travier: right
17:18:57 <travier> Usually, if a container supports running as non root, you can pick any UID for it to run under
17:18:58 <fifofonix> obviously easy to target a different uid and achieve whatever you want.  my real question was are we in alignment with 'secure by default'
17:19:29 <travier> well, we can not account for all containers in the wild in the design
17:19:34 <dustymabe> fifofonix: are you running your container as root (i.e. sudo podman run) or rootless (podman run)?
17:20:01 <fifofonix> dustymabe: well, i have a whole diveristy out there in my own wild.
17:20:21 <dustymabe> :)
17:20:37 <travier> what should we pick instead? 1001? 10000? 999?
17:20:49 <travier> I'm afraid there is no good answer
17:21:21 <fifofonix> it seems that many people are choosing 1000 by default for their non-root container images that they provision to unsophisticated users like myself.
17:21:22 <dustymabe> if I'm logged in as the core user (sudo privs and UID 1000) and I run a rootless container (podman run foo) then only UID 0 in the container maps to UID 1000 on the host. UID 1000 in the container maps to some other range of UIDs on the host (user namespaces).
17:22:37 <travier> Also note that running under UID 1000:1000 is different than running under UID 1000:1000 + sudo group + caps
17:22:40 <dustymabe> if you run a container in rootful mode (sudo podman run) then you are already doing something a little less secure (IMO) and if they break out of that then they probably already have root?
17:22:42 <jlebon> right, sudo can give root because it's setuid but it would have to be run in the context of the host, not the container
17:23:19 <dustymabe> IANA security person :)
17:23:55 <travier> (and there is SELinux)
17:24:02 <dustymabe> yep
17:24:18 <jlebon> fifofonix: TL;DR, rootless containers you start can't actually run as host-level root from inside the container
17:24:25 <travier> even a rootfull container can not read your users file by default
17:24:31 <dustymabe> fifofonix: maybe we can take this to the #fedora-coreos channel?
17:25:13 <fifofonix> sure, or elsewhere.  i'm still trying to figure out right place to raise things like this.  would it have been better to start on #fedora-coreos?
17:25:37 <dustymabe> fifofonix: yeah - you can pretty much drop anything into that channel
17:25:45 <dustymabe> another good place could be the discussion forum
17:25:57 <dustymabe> either one of those are good options
17:26:10 <fifofonix> thanks
17:26:25 <dustymabe> any other topics for open floor?
17:27:19 <dustymabe> #endmeeting