Our next speaker is Leonard Fluttering, showing up the system-D user database in here.
Hi, I guess it's not my usual crowd, but I have a particular reason why I want to talk
here, which is like, I kind of want to make more visible what system the action provides
in user database area. So my hope is that the various providers of user records would
actually implement this, and we can kind of come to a mom modern logic for registering users
in the system that can provide mom metadata. Yeah, we, where we don't trample on each other
feet as much anymore. So to summarize what I'm going to talk about this in the talk,
it's actually cut off there. So if you project provide user records to Linux systems,
I would invite you to consider just implementing system-D's IO system-D user database
modeling IPC API for it. It's kind of the whole reason why I'm here. So what is this
IO system-D dot user database thing? It's a modeling IPC API, and there's three massive
calls, one is called, get user records. It's basically, you provide a user name, our UID,
and returns to some JSON structure that is actually user record. One is called, get group records,
and I'm pretty sure you can guess well that's it. It's about returning, like, you give a
GID or a group name, and it returns to you a JSON, you're an EX group record. And then
there's memberships, which basically is specific, either group, or a user, or maybe in
course, and we'll tell you the relationships like who's in that group, or who's in which groups
are user-risk. Any sort of this, it kind of influences API to provide user or group records
to the system to your Linux system, right? System-D influences a couple of ways, but everybody
else could do the same thing. Before we continue talking, I want to, by the way, if any one
of you has questions, I really like it if we can have an interactive thing here going, so do
interrupt me and show up and we'll, sorry? Like the users, like the question was regarding
what memberships means here, like users, members of groups, right, and groups have members,
which are users, right, and the memberships just show user relationships. So, you specify,
you use a user, and then we'll return you the group, so you specify a group, and we'll turn
you user, you specify those, and then we'll return you Boolean if that's the way or not. It's
very simple. So, let's take a step back. I mentioned this word viling there. Viling is an IPC
system. It's like divas, but so much simpler, and easier, and I guess in a way, more modern.
It's based simply around SOC stream, SOC, it's like a few unique stuff, was Jason Marshalling,
and it's really, really simple, really, really simple. Much, much simpler than divas.
It has many benefits. I mean, I did talk that other conferences just why Varning is actually
a nice thing, but for us, the really essential stuff is, you know, user records need to be
resolvable and really early during boot, and they also need to be resolvable for divas itself to run.
Hence, divas is not really an option for us, because divas comes late, and divas talking to
itself to resolve user records has never been a work. So, yeah, Varning has many vending
get benefits, too many to list. The estracable stuff is awesome, rich type system. It's kind
of compatible with a web world, but still is kind of low levels of the kind of makes sense to build
them up, writing system was. So, yeah, we like a lot in system, we're slowly moving away, a little
bit from divas, like all the new APIs we kind of prefer using viling. Divas is not going to die,
it's just going to be, yeah, we kind of want to shift the focus for the new stuff, more to viling.
That has been use in system use in system D2-4-2, initially internally, but now public-2,
we have 23 APIs to find by now that just use viling in system D, and to compare that 14
APIs have been with divas. So, we kind of like, yeah, it's a lot easier to add a viling to
APIs to things than divas, because divas kind of applies a multiplex, like you basically have to
have a big event loop, and for many simple things that's just annoying. So, yeah, anyway,
this is not supposed to be talk about viling so much, just this summary is, it's an IPC system,
we like it, and it's simpler than divas. So, how does IO system to use it database work?
If you have a service, it wants to provide user records to the system,
all you do, you find a unique stock stream socket to that place, slash run system, user to beat,
and then a name of a choice, and you implement these three functions, aforementioned,
and there you go, stop. I system will do the rest for you, like for everything the system will do,
it will go through that directory, and in parallel, I'll ask all the stream sockets that are in there
for a resolution, and then take that to the results. Yeah, it's dead simple. So, to explain this
more detail, if a client wants to resolve a user, it iterates for all the sockets that are there,
connects to all of them in parallel, each time it issues the same request usually get user
record or something like this, and yeah, the first positive reply is used, or the remaining
curious is simply terminated. Except if you do enumeration, like if you have an undispecified
request, you need a specified UAD nor use a name, then of course, we'll wait for the whole
thing to respond. So, this is way simple, and glipsy NSS, you know, glipsy NSS for those
like the context is like this way, how traditionally all these enterprise identity systems
got the users registered locally, glipsy NSS is a C-based plugin API by glipsy itself.
It is quite complex, right, like because, I mean, honestly, I think there are very few people in
this world who actually properly, really understand NSS, because it comes with this programming
language that is at C NSS, which I'd call it a programming language, because it has, like,
code flow expressions, where they can say, invokes that NSS module, and then depending on the results,
go to the next module, or yeah, it's surprisingly complex for some things that sounds simple.
In this stuff, this does not exist, right, like there is no hierarchy of stuff, there's just,
yeah, we issue it in parallel. Next, it's simple, makes it robust, right, like because, yeah,
everything is timed out, not synchronous, there's no C-plug-in stuff involved, and yeah, there's
nothing to program, there's no cattle ordering of, which do you query first, you just, we just
query them all in parallel. This is actually key, right, like the fact that we call everything in
parallel, yeah, because then it doesn't really matter what's on the backend, like if you have
some slow programming language, like more Python stuff, it's totally fine for your stuff,
you're not going to slow down anything else by that. Of course, the users and groups that you
do find in that Python program are always actually going to be results for you, so we will always
wait for that, but all the other users are going to be entirely unaffected. This, of course,
only works on as a assumption that user record collisions are resolved independently, right,
in NSS, because you have this programming language that you asked this first, and this second,
this third, it's the first one wins a situation typically, except that you have this programming
language to make it more complex, but yeah, this stuff doesn't have any of this, right, like because
we ask everything in parallel, and we take the first positive answer, there is no overriding or anything,
right, like, I think that's a good thing, because, you know, if user records conflict, right,
like if there are two user records that are owned by different subsystems using the same user names,
or the same user IDs that's fatal, that means basically the security of model does also have
the window, because both the user name and the user ID are relevant for our syndication and for
access control, and if that's not unique, your single thing has a problem, so the assumption
with all of this is, yeah, you dealt with your collisions independently, you make sure
that the UAD that you allocated, the UAD range that you allocated from is not the UAD anything else
are the ones for just to use a records, an allocating from same StING for those the use of names.
This parallel curing I can explain it very easily to you, but if you actually start implementing this
this is a first-going to be a little bit more complex, because here you are an cinq significantly
in queue, multiple sockets and things like this.
To make this easier for most programming languages
as also one special service, it also is in that directory.
And that one's, we call it the multiplexer.
You can, instead of asking everyone in parallel,
you can just ask that one just once,
and it will do the parallel thing in the background
and give you the response back.
So this is like kind of the simple interface
for the little bit of complexities
that it is too, too, should request the parallel.
Yeah, it's a single method called, in this case,
no parallel stuff, very, very easy.
My recommendation would actually be for a high level
programming languages that want to use
user record resolution.
Maybe consider using this instead of always going to go
to see and wrapping the NSS.
That's a question.
It's a multi-factor application possible with the system.
If multi-factor authentication is possible in the system
once the question, no, because this is not about a syndication.
This is about registering user records
and group records and the memberships between them, that's it.
I mean, we'll talk a little bit later
about the user record form a little bit
way using which can carry information about this,
but this does not do us syndication.
It's not pan or anything like this.
This is really about the NSS stuff.
It's kind of modern interpretation of what glips the NSS does.
There's another question.
Yeah.
Some of the issues also get an effect when
they change the system with that.
This model is a little cold.
So the question was regarding change notification,
like does this color change notification
was used in a database?
No, it does not.
But the concept of rolling, of course,
allows you to do this, except that right now,
with the back answer, we have none of them
supports this really in a nice way, at least I'm not aware.
We can definitely end this, right?
I'm not sure how realistic this is.
Like in an enterprise scenario, if you have 10,000 users
and you always get notifications when a user gets
and anywhere in the enterprise, it's not going to go to a scale.
But I'm fully aware that some people want this.
We can totally extend this, right?
Like right now, it's these three functions,
because these are one-to-one, the three functions
that NSS basically, well, actually, kind of,
the function that NSS exposes.
But this doesn't mean we can go beyond that.
Obviously, quite not one of the protocols
of everything that leads to ways
to choose to turn on or be in the business.
Yeah.
I don't know what the only thing about this.
Yeah.
I mean, I'm fully think that that would be useful.
And the fact that some backups and I'm
going to support it is shouldn't not be a reason to never
support it, right?
Like it seems like a thing we can do.
Can I just ask you to also get some questions?
Yes.
OK, I'm not going to answer that.
Yeah, but I'm not going to repeat this nor answer this,
because I have a slide about this later.
OK, so let's talk about the user records.
I kind of briefly mentioned that these calls return
to user records.
So let's talk a little bit about what these user records
actually like.
These are JSON user records that we have added.
I have invented most of the formats.
We've wrote a spec about it.
Like this is where you find it.
It's inspired by, yeah, struct, post-WDDDDS, struct S,
like the shadow, and password entries.
It has basically every sentence in there
is directly translatable to fields and the JSON stuff.
Sometimes a little bit more normalized, but generally
that's all that.
It's also inspired by RC207, that's the one
that the LDAP people use for their user records,
like the Unix, what's it called again?
Unix account or something.
It's a stuff.
So there we can also map that thing very nicely,
but it has many additional fields.
I mean, don't read through all of this.
It's just all there.
It's like there's resource management there's metadata.
They are stuff for us indication, as you asked,
who was it again, that one, you were that.
So there's a lot of things there that you can configure.
Is your user records are supposed to be
extensible, so there's another question?
Yeah, so if you're obliged to, if you are going to
will your own records that apply them, please use this API,
but if I match a fleet of servers, which applies,
and you're going to have to just look at it,
which is centrally managed, currently,
you're still using this, that's a migrate way to that.
Then you set up going, why don't I get to provide you?
I'll just use something like free IPA instead.
OK, the question was regarding why this, if there's free IPA,
I think it's kind of the summary of what you think.
You shouldn't choose.
This is not what, this is not free IPA replacement or anything
like this because it has no understanding of anything remote.
This is about the local IPC system,
so that things like free IPA or more specifically
and probably SSSD could register their more complex records
locally, so this is explicitly not about remote identity management
or anything like this.
This is just about the last part of it, right?
Like when on the individual system, some signal,
like SSSD, whatever else, wants to provide these records,
let they can integrate that with system V and the rest of the world.
And one thing that Leonard will read you say in the beginning
that extending NSS API is a nightmare.
Effectively, you go through the post-standard
and all these ways down to there.
And this is a new API that is supposed to be blending data
from multiple sources, plus the data
that is not accessible through the other sources.
If your application is interested in that additional data,
that's a positive way to get that information
for the applications and for the providers to supply that data.
Later today, we will have a local authentication hop talk
where we will cover a few bits of it
how we want to use this together with the OpenS API
as before the Internet of Multi-Fighters,
so let me continue with this.
So these user records are extensible, right?
It's a JSON thing, everybody can put their fields in there.
We are totally open of adding fields there,
like in particular generic fields that there's
a big expectation that it's going to be used all around the world
from many different things.
We can add that to the specification itself,
but it's not limited to this.
Because it's JSON, we can invite people to add their own fields
for local deployments or for whatever stuff that you have,
as well, just give the fields some prefix
that makes it recognizable like do some little bit of namespacing there.
But ultimately, it's designed to be specified
that everybody can just add random stuff
to the user records if they want,
but there's a large body of standardized fields
that you're supposed to use as well.
What's also essential is there are no most side cards.
The user records is kind of comprehensive, right?
It will store those, the stuff that's traditionally
as you'd post WD, and the stuff that's in the shadow file.
Plus, it will also store things like SSH authentication keys
that are traditionally in a third side card
and you hope directory called authorized keys, right?
So it can cover all these things at a central place.
Now you might wonder, okay, there's a reason why
post WD and shadow is separated, right?
Like it's about access to these things
because they were afraid that the hash passwords
that are stored in shadow, yeah, it could be broken
if everybody can see them.
We actually replicate that thing.
So the user records are actually not just playing JSON objects.
They have a tiny bit of structure in there,
like there's sub-objects basically.
And the main part is contains the stuff
that is everybody should be able to have access
to who has access to the system.
But then there's a separate section, if you're so well,
with a privileged part.
There's actually even more stuff.
Like for some of these user records
cannot just record like the more static information
about a user, they can actually also
report something about resource usage,
and things like that.
Like for example, a back end, like one of the back ends
that provides this, for example, a home-dee reports
disk sizes, like how much space does the home directory
as a user actually currently take up as part
of the user record?
And this is also a separate section,
because this is stuff that is not stored in disk ever.
It has only makes sense on the local system
at a very temporary place.
So they're also per machine sections, by the way,
which is kind of nice too, because basically means
you can have a single static record,
but you can also have a sub-section that only
applies to one machine and not the other machines.
So that you can do even stuff like you're having a generic record
and then having the UADS signs, for example,
local to the machine.
So it's all expressible with this,
and we actually make use of this.
So we have a question about probably the advantages
about the pre-vilege specific access
based on the clients that ask sports reviews.
And I guess you won't respond about on this.
On this security.
So they're quite, yeah.
Basically, if you do a lookup, because it's an AFU next
target, we can identify who you are.
The column will just tell us.
And then, yeah, if we will suppress the shadow information
basically unless you root or you're yourself.
So this kind of replicates how this works in shadow,
except that there's no suede, or we should,
like in shadow, it's all by IPC permitives.
Let's have a brief close, close,
a look to all of this.
This is like the implementation that is in system
which is one of the providers of these user records.
You see, we're using here the vowing control tool,
which is like a command line tool that allows you
to talk to a marketing service and see what they actually provide.
It just introspects that service.
This is one of the sockets that I mentioned
and shows you, it implements the IO system,
the user database interface that I'm talking about.
I cut off all of kind of stuff here
because I didn't want to crowds the slides so much.
But yeah, the key is that you see this massive call
could use a record.
It gets a user, it's an optional input,
it gets a user name, it's input, it's an optional one.
You also specify the service that you're talking to.
This is kind of redundant, but we require this simply
because we wanted to allow that single demons
can implement multiple services.
And then they need to know which service
actually being talked to, right?
So that you can have a single socket that provides
three different services that provide user records.
You can ignore this.
And then it reports every chance of records,
which is like this user record that I was talking about.
And it was a Boolean incomplete.
It indicates whether the privilege section was cut off, right?
So you know that you're lacking access to the full thing
and you only see the unproved stuff.
So that's kind of all of what it is about,
like about the technical details, like,
yeah, play around with things you will see this.
Why should you do this again?
Like, first of all, systemly will care
about these user records a lot.
And it will provide you the compatibility
in both ways with classic glypsy NSS, right?
So you get compatibility just by binding that socket,
it will show up in glypsy NSS calls.
And the other way around is, too, by the way, as well.
Like, if there's something we're just a via NSS
is would automatically get these user records
in JSON synthesized on the fly when they're requested.
There's also an instantics for the SSH public keys
to SSH, right?
So the thing that I mentioned earlier
is also rise key stuff, right?
And we have all the glim in place
so that if you provide this and the fields are filled in,
then SSHD will know this and allow access.
There is components of systemly that will do
all the resource management stuff.
Like, you know, that's quite a bit of it.
Like, nice values and variables, results, management.
All this stuff can be encoded in user records.
And you can even do it in the user records per machine, right?
Like, because we have these per machine second sections.
And we will just enforce it for you, right?
Like, because system D does all the resource management anyway.
So you can basically say, yeah, this user,
when they log in on that machine,
they can only have one CPU or something like this
in which it's just what?
Um, well, it's also important.
It's better control about the disposition
of user records.
The disposition as in concepts, I mean,
you could call it a type or a class of user,
but we didn't want to use the words
because it has so many other definitions.
So we used the word disposition.
But it basically is a really broad categorization
of what kind of user we are talking about.
This position can be something like a system user, right?
Like, it was UID below one thousand or something.
Could be a regular user, which is somebody human.
And it can be a couple of other things.
Like, there's a user of designments for containers,
username, space, stuff and things like that.
So that, I think there's seven or something
dispositions these days.
Why does this matter, this matters
because in system D, depending on what kind of user
we are talking about, behavior, slightly changes.
For example, journal D, like the login framework
system D, well, for system users,
put all the logs in the system log.
But for the wheel, like for the regular users,
it will maintain a separate log file
for each of them, separate journal file, right?
So how this was traditionally done
is simply by looking at the numeric UID, right?
But this collides with assumptions, like old setups,
and to use UIDs all over the place, right?
So it's not sufficient in these cases to derive
the disposition simply from the numeric UID.
We need something more.
Yeah, with this, we finally have a way
how to communicate the disposition, right?
So you could basically say, yes, I have user ID 500,
which is below the typical one thousand limit.
But you can still say, this is a regular user,
and that we will then cat and all that
are behavior through this.
Yeah, this is a better control of default behavior,
like in behavior, logging behavior, all kinds of things
this is used.
What I also think is really important is we kind of,
at this point nowadays, where more and more software
is not going to be written in the C anymore,
it's kind of moving to rust and high level languages.
So one problem with glipsy NSS, of course,
is the inherently a C-sing, right?
You can only implement it by exposing CAPIs
and it can consume it only by a CAPI.
And in particular, the world where everything
is static these days, it's kind of not the way it should be.
This modeling stuff, it doesn't talk about binary APIs,
and it's just all gone, and you don't have to load
untrusted code anywhere, people can just directly ask this.
Yeah, also, user to be controlled, like this tool,
that you can actually introspect all this with,
it's kind of fun too.
There's also, like, genomic integration,
like, for example, the genomic people,
they're building the genomic last thing,
and they add a lot of information
to the user records, like, for example, prefered desktop.
It choice and things like that,
and then they have in the configuration UI,
and the preferences, things, you can actually
control these settings, right?
Like, so that it can switch between preferred desktops
and language control, like, which language
you actually prefer and things like this.
So, yeah, if you're whatever enterprise thing,
provides all these fields to this,
they will automatically then hand-scan all the genomes,
not just the system, you integrate them
with all the genomes integration,
and then we presume sooner or later,
all that other desktops will follow too.
How much time do I actually still have?
10 minutes?
Five.
So, let's, I mean, I have more slides,
we can go through some of that,
they're not as important.
I'd much rather spend the rest of the time
with questions, if they're on any.
If they're no questions at this point,
I would go for this slide.
Yeah, the question.
So, you're going to have to be responsible for that.
All right, okay, I didn't understand that.
So, you showed the user record implementation
with all these fancy details,
but is it also possible to extend the query API?
Whatever it is.
I have trouble sending it, and there's to be glad.
I feel it.
Okay, so you showed the user record, right,
with all these fancy fields,
that are extensible by the application,
but is it also possible to extend the query calls,
like the three calls that you mentioned earlier,
to specifically address the query design
of one of these extensible record fields?
So, yeah, so, right now,
like in the stuff that is already in released
to some new versions,
the only two things that you can create,
like use as search keys, I use ID and username,
but in the upcoming version, we extended this,
like there's filtering by UID range,
and there is a fuzzy name search,
so that basically, yeah, we also look at the real name
focusing like that.
So, it's in there, you can search by disposition,
and a couple of other things,
there's aliases for user record.
So, we do intend to make changes to the query API,
but it's, I mean, everybody can implement
whatever they want on their interface,
that's true, but of course, it's only useful
if this is generic,
it's saying that it's actually part of our specification.
So, while I would invite everybody
to extend a JSON records with whatever the fuck they need,
I would probably not recommend them to do this,
interface the interface locally,
because we are not gonna ask for this unless it's in the spec, right?
Like, so the consumers of these records,
the clients that actually talk to the IPC servers
are probably not gonna use your extensions.
Yeah, so, but I don't know, we are happy to extend this, right?
Like, just let me know what else you need
in the stuff like, for as a filters, or,
like, once thing then, for example,
I would like to add, soonishly, is that we're not only,
we're a port information about actually existing users,
but also about user allocation ranges, right?
So, that, I don't know,
the system these dynamic user ID stuff for services
can basically report like which ranges are using,
and then we can, like, this is interesting for allocation,
like, for things like, container managers that just need
to allocate a certain range of user IDs dynamically,
that can take this information into account
and then avoid the ranges that are, like, possessed
by some component of the OS, of that answer to the question.
So, I think we are actually having two things here.
One is use of modeling as a means to communicate
between applications.
The other one is a specific use of modeling
by system D to provide these user DB API endpoints.
And I totally envisioned that there could be
an other borrowing namespaces, right?
Provided by the specific applications that consume
and expose additional information.
It may be not the multiplexer who would be collecting
that information together from them,
but certainly a different endpoints.
So, yeah, I mean, people have asked us to do things
like user record modification, right?
I think, like, I mean, if there's actual demand
about doing this, like having a generic way
how to update the user records,
we can look into doing this, but my assumption right now
is that, in particular, the enterprise these stuff,
it's rather unlikely that you would trigger
the user record changes from the client machine.
You probably would do that through some web
things somewhere else, right?
So, I don't know.
We can certainly come up with an abstract interface
to covering that, but I would probably make it separate
from the regular user database, but I don't know.
That's just details.
But we can come up with anything, like, what user one there.
There's a question.
So, the question was, like, if I can say more
about the details, how the SSH key integration works.
So, you know, SSH D has this call-out thingy.
What's it called?
Pop key command or something, something weird.
Like, this also has keys command or something.
We implement one reference implementation,
and then we just go to this and pick the data out of it.
And it's enabled by default by system D.
It's kind of annoying because they can only be one
implementer of this, and SSH D, so that's a fight.
So, I then, like, one way to address that fight, of course,
is to just give me these records, and I will do it for you.
I don't know, like, if that's not the cards,
we can certainly make it so that we call first
or, like, chain load other tools.
But I, much rather, I actually see that people just
give us the user records.
Because, I mean, if SSH D or whatever else has this
information, they implement this, and it was just, yeah.
So, basically, the way I see it is that I would really
prefer, if a thing like SSH D would just give us the data,
and we do the integration with the rest of the work,
like, lower level system stuff, then all of us trying
to do this deep integration and fighting over priorities
and fighting about who on SWATF there's a single thing
that's, like, I have to make sense of it.
Yeah, if you want to start working with welding,
ISO, as a client, also, or as a server, and trying
to understand it, you normally first used a welding
CTL command.
But there is absolutely no documentation how to actually
use it to make these calls with the multi-plexe.
It took me an hour to read through the source code
to figure out how to just call it and get, like, a C, I mean.
No, with the welding CTL command.
Well, I'm just understanding it.
Well, it's actually pretty easy.
Well, I have the only introspection call there.
But if you figure out how to do it, it's really easy.
But it takes you an hour to read the source code
to understand it.
So it would be quick to understand.
I mean, just examples how to, so the regarding documentation
generally, we have these specifications up on this thing,
where they, of course, mind times up, but anyway,
there's documentation.
You can read this.
I'm pretty, you know, there's big holes of documentation.
Like, first time I'm going to take a once you talk
to about Varlink and the C API that we provide to do
is the bigging Varlink, there's no documentation right now.
It's relatively recently become a public thing.
But so, like, if there's really some issues that you're seeing,
it just ping us and we'll see if we can do something about this.
But yeah.