Re: [systemd-devel] Storing package metadata in ELF objects

[Luca Boccassi]

On Wed, 2021-05-19 at 16:58 +0200, Mark Wielaard wrote:
> Hi Guillem,
> 
> On Wed, 2021-05-19 at 02:19 +0200, Guillem Jover wrote:
> > So this is where I guess I'm missing something. To be able to make
> > sense of the coredumps there are two things that might end up being
> > relevant, backtraces and source code. systemd-coredump might already
> > emit a backtrace, and depending on the information provided it might
> > be more or less useful. If one needs the actual debug symbols there's
> > already some external querying/fetching required, and if distribution
> > specific source code is required because many distributions patch
> > upstream source, then even more querying/fetching will be required.
> > 
> > Which is why I'm not seeing why this standalone and isolated metadata
> > would be of much help by itself. As in, the way I see it, either the
> > information from systemd (w/o the extra metadata) is sufficient to
> > track down bugs, or that querying/fetching would be needed anyway, at
> > which point the metadata can be inferred too then?
> 
> Because without that metadata you cannot easily figure out where/how to
> get the files needed to properly track down the bugs. But using that
> metadata you can figure out where the debuginfod server is that can
> provide all that information for the binaries/core files (or a distro
> specific method if the distributor doesn't have a debuginfod server
> yet).

Yes, that is a good use case. Another use case is that the person (or
bot) who first looks at the journal with the crash notification and the
metadata might not necessarily be the one that does the full in-depth
debugging. First level support will look at things and go "oh this is
from package X at version Y, therefore team Z needs to chime in".
Or it can see that it's version A.B.C, which is listed as known buggy,
and ignore the issue. Or a myriad of other combinations.

Then there are automated systems, parsing logs and creating tickets.
Having the structured metadata available in the journal in the crash
message means much more complex and useful querying and ticket creation
systems can be set up. You _cannot_ just go and query random remote
internet servers from these systems, they need to be network-isolated,
as logs can have confidential data from customers.

The main point is, there are many many things that happen between a
crash and the team owning the component looking up debugging symbols
and loading core files. This feature is very very useful for a whole
lot of those things.

> > Oh, I was thinking about those mixed environments, full chroots or
> > stripped down containers, from different vendors, but affecting Debian
> > installations. What I'm also probably missing here is how does the
> > metadata help for a third-party that is not expected to track/keep/upload
> > debug symbols nor source packages into some repository, because otherwise
> > I'm not seeing how they'd make use of the cores (if they are insufficient
> > by themselves) to debug issues? I guess my question back would be what
> > would they do with the metadata if they do not have the debug symbols
> > nor the sources readily available? Also assuming of course they exercise
> > good practices such as never reusing the same package-version-arch tuple
> > for different builds, and similar. :)
> 
> Different builds will have different build-ids, so they can be kept
> apart. But even if without the distributor having added debuginfod
> meta-data and providing a server to fetch the extra symbols, debuginfo,
> sources, the extra meta-data is useful to administrators. Just seeing
> that crashes are associated with specific distro/version/packages helps
> narrow down instabilities.

Precisely - again this is a very much real use case. In my case, the
engineers doing support and looking at the logs (and only at the logs -
no access to the running systems is permitted) _want_ this, because it
helps them. Being able to know at a glance to the journal exactly what
is borken, with version info, is extremely valuable to them.

Yes the version info might not be precise for a minority of use cases
that override the binary version with something different than the
source version, but that's fine as it's far and few, mostly affects
metapackages, and even then it can be documented clearly that the
reference is to the source version, not the binary one.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[Pekka Paalanen]

On Sat, 22 May 2021 16:18:35 -0400
nerdopolis  wrote:

> On Saturday, May 22, 2021 3:14:27 PM EDT Pekka Paalanen wrote:
> > On Sat, 22 May 2021 09:04:42 -0400
> > nerdopolis  wrote:
> >   
> > > On Saturday, May 22, 2021 6:50:09 AM EDT Pekka Paalanen wrote:  
> > > > On Fri, 21 May 2021 21:29:09 -0400
> > > > nerdopolis  wrote:
> > > > 
> > > > > Sorry, I got the terminology mixed up again. I am still using TTYs to 
> > > > > run the
> > > > > instances of `cage`. It's the kernel mode VT emulators I am replacing 
> > > > > with the
> > > > > user mode terminal emulators (running under a fullscreen Wayland 
> > > > > compositor)
> > > > 
> > > > Hi,
> > > > 
> > > > I'm trying to clarify things for everyone here, since I think I can
> > > > guess what you want to achieve, but you have a hard time explaining
> > > > your original goal. I hope you don't mind.
> > > > 
> > > > 
> > > That's fine. Thanks!  
> > > > Starting from the outermost "layer" and going inwards:
> > > > 
> > > > 1.a Have a system service, that takes over VT 1, changes user to
> > > > 'vtty', and runs 'cage' which is a Wayland compositor, mostly
> > > > unprivileged.
> > > > 
> > > > OR
> > > > 
> > > > 1.b Have a system service, that takes over a seat directly, as the
> > > > kernel has the VT system disabled (or the seat is not seat0).
> > > > Changes user to 'vtty' and runs 'cage' mostly unprivileged.
> > > > 
> > > > 
> > > > 2. Inside cage, you run a Wayland terminal emulator as user 'vtty',
> > > >so mostly unprivileged. The terminal emulator creates a PTY.
> > > > 
> > > > 3. Inside that terminal emulator, that is, connecting to that PTY,
> > > >you want to be able log in with any user. Therefore the program
> > > >running on the PTY should present a login prompt and succeed
> > > >in logging a user in and setting up his session, and switching
> > > >to a shell running as that user.
> > > > 
> > > > All in all, this stack would replace the usual stack where
> > > > /bin/login runs directly on the TTY of a VT, allowing to use a more
> > > > featureful terminal, custom display modes, multi-output support,
> > > > maybe multiple parallel sessions for different users a la fast user
> > > > switching, and more.
> > > > 
> > > 
> > > Not to mention, getting Shift+PgUp back, (and now on multiseat systems,
> > > keyboard input from non-seat0 seats will no longer bleed into seat0 when 
> > > VT 1-6
> > > are active) :)  
> > > > Am I guessing right?
> > > 
> > > You are guessing correct. Thanks!  
> > > > 
> > > > Then the question is, how to organize all this so that it works,
> > > > and what program(s) should be used in step 3, and how?
> > > > 
> > > > 
> > > > My own proposal for this would be to run everything as systemd
> > > > system services:
> > > > 
> > > > 1. Cage runs as a system service, as user 'vtty'. Cage will require
> > > >systemd integration so that it can tell systemd when it is ready
> > > >to accept Wayland clients.
> > > > 
> > > > 2. The Wayland terminal runs as another systemd system service,
> > > >depending on the cage service, as user 'vtty'.
> > > > 
> > > That's close to what I was trying, but cage is pretty cool in this 
> > > regard, you
> > > can start
> > > cage -- vte
> > > and cage starts VTE as its only client, so the complexity of starting the
> > > wayland client externally, don't have to worry about that.  
> > 
> > But if cage starts the terminal, then systemd does not know when
> > the terminal is ready to accept a login program, or is there a way
> > to watch PTYs?
> > 
> > Ideally the terminal too would integrate with systemd start-up
> > notification IPC. Perhaps let systemd control which PTY to use, so
> > the login program/service knows to connect to the right one.
> > 
> > There's also auto-respawn, shutdown, cgroups, and more that systemd
> > can do.
> >   
> > > > 3. The login program runs as a third systemd system service,
> > > >depending on the terminal service, as user 'root' because it
> > > >needs to be able log in a user and set up a session for them.
> > > > 
> > > > That would solve the problem of how to get the necessary privileges
> > > > to log in a user, but all the other details I'm not sure.
> > > > 
> > > That's what I was aiming to do, wasn't sure how to connect to the service 
> > > until
> > > I found I can do that with socat a few days after I sent that first email 
> > > to 
> > > the list, but I still feel I should still clarify here.  
> > 
> > The socat thing for "connection" sounds quite wild to me. Instead,
> > I would expect to start a login program with the PTY as its std
> > in/out/err, just like it works with normal VT TTY logins.
> >   
> 
> Sounds like you would need to make VTE start up with nothing running, and have
> VTE report the PTY that it got?

Yes, almost. Hack VTE to use only the PTY you set via systemd. Let VTE
keep on running even if nothing has the PTY open. S