WEBVTT 00:00.000 --> 00:15.000 Our next speaker is Leonard Fluttering, showing up the system-D user database in here. 00:15.000 --> 00:21.600 Hi, I guess it's not my usual crowd, but I have a particular reason why I want to talk 00:21.600 --> 00:27.600 here, which is like, I kind of want to make more visible what system the action provides 00:27.600 --> 00:36.600 in user database area. So my hope is that the various providers of user records would 00:36.600 --> 00:45.120 actually implement this, and we can kind of come to a mom modern logic for registering users 00:45.120 --> 00:51.280 in the system that can provide mom metadata. Yeah, we, where we don't trample on each other 00:51.280 --> 00:59.280 feet as much anymore. So to summarize what I'm going to talk about this in the talk, 00:59.280 --> 01:04.480 it's actually cut off there. So if you project provide user records to Linux systems, 01:04.480 --> 01:09.040 I would invite you to consider just implementing system-D's IO system-D user database 01:09.040 --> 01:14.120 modeling IPC API for it. It's kind of the whole reason why I'm here. So what is this 01:14.120 --> 01:20.040 IO system-D dot user database thing? It's a modeling IPC API, and there's three massive 01:20.040 --> 01:26.040 calls, one is called, get user records. It's basically, you provide a user name, our UID, 01:26.040 --> 01:30.680 and returns to some JSON structure that is actually user record. One is called, get group records, 01:30.680 --> 01:34.760 and I'm pretty sure you can guess well that's it. It's about returning, like, you give a 01:34.760 --> 01:40.920 GID or a group name, and it returns to you a JSON, you're an EX group record. And then 01:40.920 --> 01:47.320 there's memberships, which basically is specific, either group, or a user, or maybe in 01:47.320 --> 01:53.720 course, and we'll tell you the relationships like who's in that group, or who's in which groups 01:53.720 --> 01:59.720 are user-risk. Any sort of this, it kind of influences API to provide user or group records 01:59.720 --> 02:05.960 to the system to your Linux system, right? System-D influences a couple of ways, but everybody 02:05.960 --> 02:11.080 else could do the same thing. Before we continue talking, I want to, by the way, if any one 02:11.080 --> 02:16.040 of you has questions, I really like it if we can have an interactive thing here going, so do 02:16.040 --> 02:26.520 interrupt me and show up and we'll, sorry? Like the users, like the question was regarding 02:26.520 --> 02:31.720 what memberships means here, like users, members of groups, right, and groups have members, 02:31.720 --> 02:36.280 which are users, right, and the memberships just show user relationships. So, you specify, 02:36.280 --> 02:39.880 you use a user, and then we'll return you the group, so you specify a group, and we'll turn 02:39.880 --> 02:45.160 you user, you specify those, and then we'll return you Boolean if that's the way or not. It's 02:45.160 --> 02:50.440 very simple. So, let's take a step back. I mentioned this word viling there. Viling is an IPC 02:50.440 --> 02:57.880 system. It's like divas, but so much simpler, and easier, and I guess in a way, more modern. 02:59.480 --> 03:04.440 It's based simply around SOC stream, SOC, it's like a few unique stuff, was Jason Marshalling, 03:04.440 --> 03:08.440 and it's really, really simple, really, really simple. Much, much simpler than divas. 03:09.800 --> 03:14.600 It has many benefits. I mean, I did talk that other conferences just why Varning is actually 03:14.680 --> 03:20.440 a nice thing, but for us, the really essential stuff is, you know, user records need to be 03:20.440 --> 03:27.160 resolvable and really early during boot, and they also need to be resolvable for divas itself to run. 03:27.160 --> 03:33.320 Hence, divas is not really an option for us, because divas comes late, and divas talking to 03:33.320 --> 03:38.680 itself to resolve user records has never been a work. So, yeah, Varning has many vending 03:38.680 --> 03:43.960 get benefits, too many to list. The estracable stuff is awesome, rich type system. It's kind 03:43.960 --> 03:48.600 of compatible with a web world, but still is kind of low levels of the kind of makes sense to build 03:48.600 --> 03:54.040 them up, writing system was. So, yeah, we like a lot in system, we're slowly moving away, a little 03:54.040 --> 03:58.280 bit from divas, like all the new APIs we kind of prefer using viling. Divas is not going to die, 03:58.280 --> 04:03.320 it's just going to be, yeah, we kind of want to shift the focus for the new stuff, more to viling. 04:03.960 --> 04:11.480 That has been use in system use in system D2-4-2, initially internally, but now public-2, 04:11.480 --> 04:17.480 we have 23 APIs to find by now that just use viling in system D, and to compare that 14 04:17.480 --> 04:25.160 APIs have been with divas. So, we kind of like, yeah, it's a lot easier to add a viling to 04:25.160 --> 04:30.600 APIs to things than divas, because divas kind of applies a multiplex, like you basically have to 04:30.600 --> 04:37.320 have a big event loop, and for many simple things that's just annoying. So, yeah, anyway, 04:37.320 --> 04:42.040 this is not supposed to be talk about viling so much, just this summary is, it's an IPC system, 04:42.040 --> 04:48.040 we like it, and it's simpler than divas. So, how does IO system to use it database work? 04:49.480 --> 04:52.520 If you have a service, it wants to provide user records to the system, 04:53.160 --> 04:58.920 all you do, you find a unique stock stream socket to that place, slash run system, user to beat, 04:59.080 --> 05:04.200 and then a name of a choice, and you implement these three functions, aforementioned, 05:05.480 --> 05:11.000 and there you go, stop. I system will do the rest for you, like for everything the system will do, 05:11.000 --> 05:16.360 it will go through that directory, and in parallel, I'll ask all the stream sockets that are in there 05:16.360 --> 05:25.720 for a resolution, and then take that to the results. Yeah, it's dead simple. So, to explain this 05:25.720 --> 05:30.840 more detail, if a client wants to resolve a user, it iterates for all the sockets that are there, 05:32.120 --> 05:37.720 connects to all of them in parallel, each time it issues the same request usually get user 05:37.720 --> 05:44.280 record or something like this, and yeah, the first positive reply is used, or the remaining 05:44.280 --> 05:50.120 curious is simply terminated. Except if you do enumeration, like if you have an undispecified 05:50.120 --> 05:55.560 request, you need a specified UAD nor use a name, then of course, we'll wait for the whole 05:55.560 --> 06:02.520 thing to respond. So, this is way simple, and glipsy NSS, you know, glipsy NSS for those 06:03.560 --> 06:10.360 like the context is like this way, how traditionally all these enterprise identity systems 06:10.360 --> 06:16.440 got the users registered locally, glipsy NSS is a C-based plugin API by glipsy itself. 06:17.640 --> 06:22.440 It is quite complex, right, like because, I mean, honestly, I think there are very few people in 06:22.440 --> 06:26.840 this world who actually properly, really understand NSS, because it comes with this programming 06:26.840 --> 06:32.200 language that is at C NSS, which I'd call it a programming language, because it has, like, 06:32.200 --> 06:37.480 code flow expressions, where they can say, invokes that NSS module, and then depending on the results, 06:37.480 --> 06:43.320 go to the next module, or yeah, it's surprisingly complex for some things that sounds simple. 06:43.320 --> 06:48.920 In this stuff, this does not exist, right, like there is no hierarchy of stuff, there's just, 06:49.080 --> 06:55.480 yeah, we issue it in parallel. Next, it's simple, makes it robust, right, like because, yeah, 06:55.480 --> 07:02.200 everything is timed out, not synchronous, there's no C-plug-in stuff involved, and yeah, there's 07:02.200 --> 07:07.640 nothing to program, there's no cattle ordering of, which do you query first, you just, we just 07:07.640 --> 07:14.280 query them all in parallel. This is actually key, right, like the fact that we call everything in 07:14.360 --> 07:20.120 parallel, yeah, because then it doesn't really matter what's on the backend, like if you have 07:20.120 --> 07:24.600 some slow programming language, like more Python stuff, it's totally fine for your stuff, 07:25.400 --> 07:31.000 you're not going to slow down anything else by that. Of course, the users and groups that you 07:31.000 --> 07:35.400 do find in that Python program are always actually going to be results for you, so we will always 07:35.400 --> 07:40.840 wait for that, but all the other users are going to be entirely unaffected. This, of course, 07:40.840 --> 07:44.920 only works on as a assumption that user record collisions are resolved independently, right, 07:45.560 --> 07:49.640 in NSS, because you have this programming language that you asked this first, and this second, 07:49.640 --> 07:54.040 this third, it's the first one wins a situation typically, except that you have this programming 07:54.040 --> 07:58.600 language to make it more complex, but yeah, this stuff doesn't have any of this, right, like because 07:58.600 --> 08:04.040 we ask everything in parallel, and we take the first positive answer, there is no overriding or anything, 08:04.040 --> 08:08.440 right, like, I think that's a good thing, because, you know, if user records conflict, right, 08:08.440 --> 08:14.120 like if there are two user records that are owned by different subsystems using the same user names, 08:14.120 --> 08:18.840 or the same user IDs that's fatal, that means basically the security of model does also have 08:18.840 --> 08:25.160 the window, because both the user name and the user ID are relevant for our syndication and for 08:25.160 --> 08:33.240 access control, and if that's not unique, your single thing has a problem, so the assumption 08:33.320 --> 08:37.960 with all of this is, yeah, you dealt with your collisions independently, you make sure 08:37.960 --> 08:43.320 that the UAD that you allocated, the UAD range that you allocated from is not the UAD anything else 08:43.320 --> 08:47.800 are the ones for just to use a records, an allocating from same StING for those the use of names. 08:50.760 --> 08:56.520 This parallel curing I can explain it very easily to you, but if you actually start implementing this 08:56.520 --> 08:59.560 this is a first-going to be a little bit more complex, because here you are an cinq significantly 08:59.560 --> 09:02.040 in queue, multiple sockets and things like this. 09:02.040 --> 09:04.560 To make this easier for most programming languages 09:04.560 --> 09:08.560 as also one special service, it also is in that directory. 09:08.560 --> 09:12.280 And that one's, we call it the multiplexer. 09:12.280 --> 09:15.120 You can, instead of asking everyone in parallel, 09:15.120 --> 09:17.880 you can just ask that one just once, 09:17.880 --> 09:20.640 and it will do the parallel thing in the background 09:20.640 --> 09:22.360 and give you the response back. 09:22.360 --> 09:26.600 So this is like kind of the simple interface 09:26.600 --> 09:28.240 for the little bit of complexities 09:28.240 --> 09:31.600 that it is too, too, should request the parallel. 09:31.600 --> 09:33.720 Yeah, it's a single method called, in this case, 09:33.720 --> 09:35.680 no parallel stuff, very, very easy. 09:35.680 --> 09:38.720 My recommendation would actually be for a high level 09:38.720 --> 09:40.240 programming languages that want to use 09:40.240 --> 09:41.640 user record resolution. 09:41.640 --> 09:44.000 Maybe consider using this instead of always going to go 09:44.000 --> 09:45.120 to see and wrapping the NSS. 09:45.120 --> 09:46.120 That's a question. 09:46.120 --> 09:49.840 It's a multi-factor application possible with the system. 09:49.840 --> 09:52.440 If multi-factor authentication is possible in the system 09:52.440 --> 09:55.240 once the question, no, because this is not about a syndication. 09:55.240 --> 09:56.760 This is about registering user records 09:56.760 --> 10:00.560 and group records and the memberships between them, that's it. 10:00.560 --> 10:01.920 I mean, we'll talk a little bit later 10:01.920 --> 10:03.120 about the user record form a little bit 10:03.120 --> 10:05.040 way using which can carry information about this, 10:05.040 --> 10:07.800 but this does not do us syndication. 10:07.800 --> 10:09.560 It's not pan or anything like this. 10:09.560 --> 10:12.200 This is really about the NSS stuff. 10:12.200 --> 10:15.200 It's kind of modern interpretation of what glips the NSS does. 10:15.200 --> 10:16.440 There's another question. 10:16.440 --> 10:17.440 Yeah. 10:17.440 --> 10:19.840 Some of the issues also get an effect when 10:19.840 --> 10:22.720 they change the system with that. 10:22.720 --> 10:25.400 This model is a little cold. 10:25.560 --> 10:28.560 So the question was regarding change notification, 10:28.560 --> 10:30.440 like does this color change notification 10:30.440 --> 10:31.600 was used in a database? 10:31.600 --> 10:32.920 No, it does not. 10:32.920 --> 10:35.160 But the concept of rolling, of course, 10:35.160 --> 10:37.760 allows you to do this, except that right now, 10:37.760 --> 10:39.200 with the back answer, we have none of them 10:39.200 --> 10:42.640 supports this really in a nice way, at least I'm not aware. 10:42.640 --> 10:44.880 We can definitely end this, right? 10:44.880 --> 10:46.520 I'm not sure how realistic this is. 10:46.520 --> 10:49.040 Like in an enterprise scenario, if you have 10,000 users 10:49.040 --> 10:51.000 and you always get notifications when a user gets 10:51.000 --> 10:53.680 and anywhere in the enterprise, it's not going to go to a scale. 10:53.680 --> 10:56.520 But I'm fully aware that some people want this. 10:56.520 --> 10:57.880 We can totally extend this, right? 10:57.880 --> 10:59.240 Like right now, it's these three functions, 10:59.240 --> 11:01.560 because these are one-to-one, the three functions 11:01.560 --> 11:05.680 that NSS basically, well, actually, kind of, 11:05.680 --> 11:07.680 the function that NSS exposes. 11:07.680 --> 11:10.200 But this doesn't mean we can go beyond that. 11:10.200 --> 11:13.240 Obviously, quite not one of the protocols 11:13.240 --> 11:14.880 of everything that leads to ways 11:14.880 --> 11:17.600 to choose to turn on or be in the business. 11:17.600 --> 11:18.440 Yeah. 11:18.440 --> 11:20.240 I don't know what the only thing about this. 11:20.240 --> 11:21.440 Yeah. 11:21.440 --> 11:24.040 I mean, I'm fully think that that would be useful. 11:24.040 --> 11:25.520 And the fact that some backups and I'm 11:25.520 --> 11:28.120 going to support it is shouldn't not be a reason to never 11:28.120 --> 11:28.680 support it, right? 11:28.680 --> 11:31.240 Like it seems like a thing we can do. 11:31.240 --> 11:34.960 Can I just ask you to also get some questions? 11:34.960 --> 11:35.960 Yes. 11:35.960 --> 11:38.120 OK, I'm not going to answer that. 11:38.120 --> 11:40.200 Yeah, but I'm not going to repeat this nor answer this, 11:40.200 --> 11:42.480 because I have a slide about this later. 11:42.480 --> 11:46.960 OK, so let's talk about the user records. 11:46.960 --> 11:49.520 I kind of briefly mentioned that these calls return 11:49.520 --> 11:50.120 to user records. 11:50.120 --> 11:51.800 So let's talk a little bit about what these user records 11:51.800 --> 11:53.520 actually like. 11:53.520 --> 11:55.520 These are JSON user records that we have added. 11:55.520 --> 11:57.360 I have invented most of the formats. 11:57.360 --> 11:58.800 We've wrote a spec about it. 11:58.800 --> 12:00.960 Like this is where you find it. 12:00.960 --> 12:05.640 It's inspired by, yeah, struct, post-WDDDDS, struct S, 12:05.640 --> 12:07.800 like the shadow, and password entries. 12:07.800 --> 12:09.800 It has basically every sentence in there 12:09.800 --> 12:13.720 is directly translatable to fields and the JSON stuff. 12:13.720 --> 12:16.000 Sometimes a little bit more normalized, but generally 12:16.000 --> 12:18.520 that's all that. 12:18.520 --> 12:21.080 It's also inspired by RC207, that's the one 12:21.080 --> 12:25.400 that the LDAP people use for their user records, 12:25.400 --> 12:26.800 like the Unix, what's it called again? 12:26.800 --> 12:27.800 Unix account or something. 12:27.800 --> 12:29.000 It's a stuff. 12:29.000 --> 12:31.520 So there we can also map that thing very nicely, 12:31.520 --> 12:33.400 but it has many additional fields. 12:33.400 --> 12:35.640 I mean, don't read through all of this. 12:35.640 --> 12:36.760 It's just all there. 12:36.760 --> 12:39.320 It's like there's resource management there's metadata. 12:39.320 --> 12:41.880 They are stuff for us indication, as you asked, 12:41.880 --> 12:45.600 who was it again, that one, you were that. 12:45.600 --> 12:52.160 So there's a lot of things there that you can configure. 12:52.160 --> 12:53.720 Is your user records are supposed to be 12:53.720 --> 12:56.360 extensible, so there's another question? 12:56.360 --> 12:59.600 Yeah, so if you're obliged to, if you are going to 12:59.600 --> 13:04.720 will your own records that apply them, please use this API, 13:04.720 --> 13:08.840 but if I match a fleet of servers, which applies, 13:08.840 --> 13:11.160 and you're going to have to just look at it, 13:11.160 --> 13:13.240 which is centrally managed, currently, 13:13.240 --> 13:16.320 you're still using this, that's a migrate way to that. 13:16.320 --> 13:18.920 Then you set up going, why don't I get to provide you? 13:18.920 --> 13:22.480 I'll just use something like free IPA instead. 13:22.480 --> 13:25.560 OK, the question was regarding why this, if there's free IPA, 13:25.560 --> 13:28.640 I think it's kind of the summary of what you think. 13:28.640 --> 13:29.480 You shouldn't choose. 13:29.480 --> 13:32.640 This is not what, this is not free IPA replacement or anything 13:32.640 --> 13:35.320 like this because it has no understanding of anything remote. 13:35.320 --> 13:37.440 This is about the local IPC system, 13:37.440 --> 13:40.400 so that things like free IPA or more specifically 13:40.400 --> 13:44.120 and probably SSSD could register their more complex records 13:44.120 --> 13:48.200 locally, so this is explicitly not about remote identity management 13:48.200 --> 13:49.240 or anything like this. 13:49.240 --> 13:52.400 This is just about the last part of it, right? 13:52.400 --> 13:55.680 Like when on the individual system, some signal, 13:55.680 --> 13:58.320 like SSSD, whatever else, wants to provide these records, 13:58.320 --> 14:02.200 let they can integrate that with system V and the rest of the world. 14:02.200 --> 14:06.560 And one thing that Leonard will read you say in the beginning 14:06.560 --> 14:11.720 that extending NSS API is a nightmare. 14:11.720 --> 14:14.320 Effectively, you go through the post-standard 14:14.320 --> 14:19.680 and all these ways down to there. 14:19.680 --> 14:25.400 And this is a new API that is supposed to be blending data 14:25.400 --> 14:28.960 from multiple sources, plus the data 14:28.960 --> 14:33.000 that is not accessible through the other sources. 14:33.000 --> 14:37.800 If your application is interested in that additional data, 14:37.800 --> 14:41.120 that's a positive way to get that information 14:41.120 --> 14:45.320 for the applications and for the providers to supply that data. 14:45.320 --> 14:49.840 Later today, we will have a local authentication hop talk 14:49.840 --> 14:52.120 where we will cover a few bits of it 14:52.120 --> 14:57.080 how we want to use this together with the OpenS API 14:57.080 --> 14:59.840 as before the Internet of Multi-Fighters, 14:59.840 --> 15:04.240 so let me continue with this. 15:04.240 --> 15:06.080 So these user records are extensible, right? 15:06.080 --> 15:09.280 It's a JSON thing, everybody can put their fields in there. 15:09.280 --> 15:11.360 We are totally open of adding fields there, 15:11.360 --> 15:13.920 like in particular generic fields that there's 15:13.920 --> 15:16.480 a big expectation that it's going to be used all around the world 15:16.480 --> 15:18.240 from many different things. 15:18.240 --> 15:19.960 We can add that to the specification itself, 15:19.960 --> 15:21.720 but it's not limited to this. 15:21.720 --> 15:24.720 Because it's JSON, we can invite people to add their own fields 15:24.720 --> 15:28.440 for local deployments or for whatever stuff that you have, 15:28.440 --> 15:32.680 as well, just give the fields some prefix 15:32.680 --> 15:36.120 that makes it recognizable like do some little bit of namespacing there. 15:36.120 --> 15:38.160 But ultimately, it's designed to be specified 15:38.160 --> 15:40.280 that everybody can just add random stuff 15:40.280 --> 15:43.200 to the user records if they want, 15:43.200 --> 15:45.480 but there's a large body of standardized fields 15:45.480 --> 15:48.400 that you're supposed to use as well. 15:48.400 --> 15:50.200 What's also essential is there are no most side cards. 15:50.200 --> 15:53.480 The user records is kind of comprehensive, right? 15:53.480 --> 15:56.320 It will store those, the stuff that's traditionally 15:56.320 --> 16:00.920 as you'd post WD, and the stuff that's in the shadow file. 16:00.920 --> 16:05.040 Plus, it will also store things like SSH authentication keys 16:05.040 --> 16:07.040 that are traditionally in a third side card 16:07.040 --> 16:10.120 and you hope directory called authorized keys, right? 16:10.120 --> 16:13.920 So it can cover all these things at a central place. 16:13.920 --> 16:17.360 Now you might wonder, okay, there's a reason why 16:17.360 --> 16:19.520 post WD and shadow is separated, right? 16:19.520 --> 16:21.840 Like it's about access to these things 16:21.840 --> 16:26.400 because they were afraid that the hash passwords 16:26.400 --> 16:30.320 that are stored in shadow, yeah, it could be broken 16:30.320 --> 16:31.840 if everybody can see them. 16:31.840 --> 16:33.280 We actually replicate that thing. 16:33.280 --> 16:36.520 So the user records are actually not just playing JSON objects. 16:36.520 --> 16:39.360 They have a tiny bit of structure in there, 16:39.360 --> 16:42.360 like there's sub-objects basically. 16:42.360 --> 16:45.840 And the main part is contains the stuff 16:45.840 --> 16:47.920 that is everybody should be able to have access 16:47.920 --> 16:50.080 to who has access to the system. 16:50.080 --> 16:54.080 But then there's a separate section, if you're so well, 16:54.080 --> 16:55.320 with a privileged part. 16:55.320 --> 16:56.440 There's actually even more stuff. 16:56.440 --> 16:57.760 Like for some of these user records 16:57.760 --> 17:01.080 cannot just record like the more static information 17:01.080 --> 17:03.080 about a user, they can actually also 17:03.080 --> 17:04.960 report something about resource usage, 17:04.960 --> 17:05.800 and things like that. 17:05.800 --> 17:09.320 Like for example, a back end, like one of the back ends 17:09.320 --> 17:13.880 that provides this, for example, a home-dee reports 17:13.880 --> 17:17.320 disk sizes, like how much space does the home directory 17:17.320 --> 17:19.840 as a user actually currently take up as part 17:19.840 --> 17:20.840 of the user record? 17:20.840 --> 17:22.080 And this is also a separate section, 17:22.080 --> 17:25.160 because this is stuff that is not stored in disk ever. 17:25.160 --> 17:27.440 It has only makes sense on the local system 17:27.440 --> 17:29.640 at a very temporary place. 17:29.640 --> 17:31.760 So they're also per machine sections, by the way, 17:31.760 --> 17:33.800 which is kind of nice too, because basically means 17:33.800 --> 17:35.040 you can have a single static record, 17:35.040 --> 17:36.680 but you can also have a sub-section that only 17:36.680 --> 17:39.280 applies to one machine and not the other machines. 17:39.280 --> 17:42.360 So that you can do even stuff like you're having a generic record 17:42.360 --> 17:44.720 and then having the UADS signs, for example, 17:44.720 --> 17:46.240 local to the machine. 17:46.240 --> 17:47.640 So it's all expressible with this, 17:47.640 --> 17:49.320 and we actually make use of this. 17:49.320 --> 17:52.800 So we have a question about probably the advantages 17:52.800 --> 17:57.280 about the pre-vilege specific access 17:57.280 --> 18:00.680 based on the clients that ask sports reviews. 18:00.680 --> 18:04.960 And I guess you won't respond about on this. 18:04.960 --> 18:06.640 On this security. 18:06.640 --> 18:08.200 So they're quite, yeah. 18:08.200 --> 18:13.160 Basically, if you do a lookup, because it's an AFU next 18:13.160 --> 18:15.920 target, we can identify who you are. 18:15.920 --> 18:17.360 The column will just tell us. 18:17.360 --> 18:21.200 And then, yeah, if we will suppress the shadow information 18:21.200 --> 18:26.000 basically unless you root or you're yourself. 18:26.000 --> 18:28.280 So this kind of replicates how this works in shadow, 18:28.280 --> 18:31.280 except that there's no suede, or we should, 18:31.280 --> 18:36.360 like in shadow, it's all by IPC permitives. 18:36.360 --> 18:38.920 Let's have a brief close, close, 18:38.920 --> 18:39.840 a look to all of this. 18:39.840 --> 18:41.600 This is like the implementation that is in system 18:42.080 --> 18:45.840 which is one of the providers of these user records. 18:45.840 --> 18:49.200 You see, we're using here the vowing control tool, 18:49.200 --> 18:52.200 which is like a command line tool that allows you 18:52.200 --> 18:54.680 to talk to a marketing service and see what they actually provide. 18:54.680 --> 18:56.000 It just introspects that service. 18:56.000 --> 18:57.680 This is one of the sockets that I mentioned 18:57.680 --> 18:59.640 and shows you, it implements the IO system, 18:59.640 --> 19:02.080 the user database interface that I'm talking about. 19:02.080 --> 19:03.760 I cut off all of kind of stuff here 19:03.760 --> 19:08.760 because I didn't want to crowds the slides so much. 19:09.280 --> 19:11.600 But yeah, the key is that you see this massive call 19:11.600 --> 19:12.720 could use a record. 19:12.720 --> 19:15.200 It gets a user, it's an optional input, 19:15.200 --> 19:17.520 it gets a user name, it's input, it's an optional one. 19:17.520 --> 19:20.680 You also specify the service that you're talking to. 19:20.680 --> 19:23.360 This is kind of redundant, but we require this simply 19:23.360 --> 19:26.800 because we wanted to allow that single demons 19:26.800 --> 19:28.560 can implement multiple services. 19:28.560 --> 19:30.120 And then they need to know which service 19:30.120 --> 19:31.200 actually being talked to, right? 19:31.200 --> 19:33.560 So that you can have a single socket that provides 19:33.560 --> 19:36.720 three different services that provide user records. 19:36.720 --> 19:37.560 You can ignore this. 19:37.560 --> 19:39.320 And then it reports every chance of records, 19:39.320 --> 19:41.600 which is like this user record that I was talking about. 19:41.600 --> 19:44.360 And it was a Boolean incomplete. 19:44.360 --> 19:49.360 It indicates whether the privilege section was cut off, right? 19:49.480 --> 19:52.880 So you know that you're lacking access to the full thing 19:52.880 --> 19:54.800 and you only see the unproved stuff. 19:57.080 --> 20:00.120 So that's kind of all of what it is about, 20:00.120 --> 20:01.520 like about the technical details, like, 20:01.520 --> 20:03.680 yeah, play around with things you will see this. 20:04.880 --> 20:06.000 Why should you do this again? 20:06.000 --> 20:08.280 Like, first of all, systemly will care 20:08.280 --> 20:09.680 about these user records a lot. 20:09.680 --> 20:11.280 And it will provide you the compatibility 20:11.280 --> 20:14.080 in both ways with classic glypsy NSS, right? 20:14.080 --> 20:18.320 So you get compatibility just by binding that socket, 20:18.320 --> 20:21.240 it will show up in glypsy NSS calls. 20:21.240 --> 20:23.240 And the other way around is, too, by the way, as well. 20:23.240 --> 20:25.400 Like, if there's something we're just a via NSS 20:25.400 --> 20:27.120 is would automatically get these user records 20:27.120 --> 20:30.720 in JSON synthesized on the fly when they're requested. 20:30.720 --> 20:33.680 There's also an instantics for the SSH public keys 20:33.680 --> 20:34.600 to SSH, right? 20:34.600 --> 20:36.120 So the thing that I mentioned earlier 20:36.120 --> 20:37.800 is also rise key stuff, right? 20:37.800 --> 20:39.000 And we have all the glim in place 20:39.000 --> 20:41.800 so that if you provide this and the fields are filled in, 20:41.800 --> 20:44.640 then SSHD will know this and allow access. 20:44.640 --> 20:47.600 There is components of systemly that will do 20:47.600 --> 20:48.760 all the resource management stuff. 20:48.760 --> 20:50.680 Like, you know, that's quite a bit of it. 20:50.680 --> 20:53.320 Like, nice values and variables, results, management. 20:53.320 --> 20:56.680 All this stuff can be encoded in user records. 20:56.680 --> 20:59.480 And you can even do it in the user records per machine, right? 20:59.480 --> 21:02.000 Like, because we have these per machine second sections. 21:02.000 --> 21:03.520 And we will just enforce it for you, right? 21:03.520 --> 21:06.720 Like, because system D does all the resource management anyway. 21:06.720 --> 21:09.160 So you can basically say, yeah, this user, 21:09.160 --> 21:10.400 when they log in on that machine, 21:10.400 --> 21:12.520 they can only have one CPU or something like this 21:12.520 --> 21:13.760 in which it's just what? 21:13.760 --> 21:16.880 Um, well, it's also important. 21:16.880 --> 21:18.520 It's better control about the disposition 21:18.520 --> 21:19.520 of user records. 21:19.520 --> 21:21.800 The disposition as in concepts, I mean, 21:21.800 --> 21:23.920 you could call it a type or a class of user, 21:23.920 --> 21:26.360 but we didn't want to use the words 21:26.360 --> 21:28.960 because it has so many other definitions. 21:28.960 --> 21:30.160 So we used the word disposition. 21:30.160 --> 21:32.680 But it basically is a really broad categorization 21:32.680 --> 21:35.080 of what kind of user we are talking about. 21:35.080 --> 21:37.360 This position can be something like a system user, right? 21:37.360 --> 21:39.560 Like, it was UID below one thousand or something. 21:39.560 --> 21:42.240 Could be a regular user, which is somebody human. 21:42.240 --> 21:43.960 And it can be a couple of other things. 21:43.960 --> 21:46.560 Like, there's a user of designments for containers, 21:46.560 --> 21:49.200 username, space, stuff and things like that. 21:49.200 --> 21:50.960 So that, I think there's seven or something 21:50.960 --> 21:52.720 dispositions these days. 21:52.720 --> 21:54.880 Why does this matter, this matters 21:54.880 --> 21:57.840 because in system D, depending on what kind of user 21:57.840 --> 22:00.280 we are talking about, behavior, slightly changes. 22:00.280 --> 22:03.200 For example, journal D, like the login framework 22:03.200 --> 22:05.840 system D, well, for system users, 22:05.840 --> 22:08.440 put all the logs in the system log. 22:08.440 --> 22:10.880 But for the wheel, like for the regular users, 22:10.880 --> 22:14.080 it will maintain a separate log file 22:14.080 --> 22:16.880 for each of them, separate journal file, right? 22:16.880 --> 22:19.600 So how this was traditionally done 22:19.600 --> 22:23.040 is simply by looking at the numeric UID, right? 22:23.040 --> 22:29.040 But this collides with assumptions, like old setups, 22:29.040 --> 22:31.600 and to use UIDs all over the place, right? 22:31.600 --> 22:35.160 So it's not sufficient in these cases to derive 22:35.160 --> 22:37.000 the disposition simply from the numeric UID. 22:37.000 --> 22:39.200 We need something more. 22:39.200 --> 22:41.360 Yeah, with this, we finally have a way 22:41.360 --> 22:42.960 how to communicate the disposition, right? 22:42.960 --> 22:46.000 So you could basically say, yes, I have user ID 500, 22:46.000 --> 22:49.440 which is below the typical one thousand limit. 22:49.440 --> 22:51.480 But you can still say, this is a regular user, 22:51.480 --> 22:54.480 and that we will then cat and all that 22:54.480 --> 22:56.920 are behavior through this. 22:56.920 --> 22:59.480 Yeah, this is a better control of default behavior, 22:59.480 --> 23:02.280 like in behavior, logging behavior, all kinds of things 23:02.280 --> 23:03.960 this is used. 23:03.960 --> 23:06.480 What I also think is really important is we kind of, 23:06.480 --> 23:09.120 at this point nowadays, where more and more software 23:09.120 --> 23:12.440 is not going to be written in the C anymore, 23:12.440 --> 23:15.200 it's kind of moving to rust and high level languages. 23:15.200 --> 23:17.600 So one problem with glipsy NSS, of course, 23:17.600 --> 23:18.760 is the inherently a C-sing, right? 23:18.760 --> 23:21.240 You can only implement it by exposing CAPIs 23:21.240 --> 23:23.200 and it can consume it only by a CAPI. 23:23.200 --> 23:24.500 And in particular, the world where everything 23:24.500 --> 23:28.340 is static these days, it's kind of not the way it should be. 23:28.340 --> 23:31.620 This modeling stuff, it doesn't talk about binary APIs, 23:31.620 --> 23:34.580 and it's just all gone, and you don't have to load 23:34.580 --> 23:38.380 untrusted code anywhere, people can just directly ask this. 23:38.380 --> 23:41.180 Yeah, also, user to be controlled, like this tool, 23:41.180 --> 23:42.740 that you can actually introspect all this with, 23:42.740 --> 23:45.020 it's kind of fun too. 23:45.020 --> 23:46.460 There's also, like, genomic integration, 23:46.460 --> 23:48.380 like, for example, the genomic people, 23:48.380 --> 23:50.740 they're building the genomic last thing, 23:50.740 --> 23:52.340 and they add a lot of information 23:52.340 --> 23:57.140 to the user records, like, for example, prefered desktop. 23:57.140 --> 23:59.300 It choice and things like that, 23:59.300 --> 24:01.580 and then they have in the configuration UI, 24:01.580 --> 24:03.380 and the preferences, things, you can actually 24:03.380 --> 24:04.500 control these settings, right? 24:04.500 --> 24:06.900 Like, so that it can switch between preferred desktops 24:06.900 --> 24:09.300 and language control, like, which language 24:09.300 --> 24:10.820 you actually prefer and things like this. 24:10.820 --> 24:15.020 So, yeah, if you're whatever enterprise thing, 24:15.020 --> 24:16.420 provides all these fields to this, 24:16.420 --> 24:18.580 they will automatically then hand-scan all the genomes, 24:18.580 --> 24:19.780 not just the system, you integrate them 24:19.780 --> 24:20.740 with all the genomes integration, 24:20.740 --> 24:22.020 and then we presume sooner or later, 24:22.020 --> 24:24.540 all that other desktops will follow too. 24:24.540 --> 24:26.220 How much time do I actually still have? 24:28.580 --> 24:29.420 10 minutes? 24:29.420 --> 24:30.260 Five. 24:31.540 --> 24:35.500 So, let's, I mean, I have more slides, 24:35.500 --> 24:36.900 we can go through some of that, 24:36.900 --> 24:38.060 they're not as important. 24:38.060 --> 24:40.180 I'd much rather spend the rest of the time 24:40.180 --> 24:41.860 with questions, if they're on any. 24:41.860 --> 24:43.020 If they're no questions at this point, 24:43.020 --> 24:44.500 I would go for this slide. 24:44.500 --> 24:45.580 Yeah, the question. 24:46.500 --> 24:50.060 So, you're going to have to be responsible for that. 24:50.060 --> 24:51.700 All right, okay, I didn't understand that. 24:53.700 --> 24:57.540 So, you showed the user record implementation 24:57.540 --> 24:58.500 with all these fancy details, 24:58.500 --> 25:02.060 but is it also possible to extend the query API? 25:02.060 --> 25:03.060 Whatever it is. 25:03.060 --> 25:04.900 I have trouble sending it, and there's to be glad. 25:04.900 --> 25:05.740 I feel it. 25:08.260 --> 25:09.860 Okay, so you showed the user record, right, 25:09.860 --> 25:11.020 with all these fancy fields, 25:11.020 --> 25:13.620 that are extensible by the application, 25:13.620 --> 25:16.180 but is it also possible to extend the query calls, 25:16.180 --> 25:19.540 like the three calls that you mentioned earlier, 25:19.540 --> 25:22.260 to specifically address the query design 25:22.260 --> 25:25.020 of one of these extensible record fields? 25:25.020 --> 25:29.020 So, yeah, so, right now, 25:29.020 --> 25:30.940 like in the stuff that is already in released 25:30.940 --> 25:31.980 to some new versions, 25:31.980 --> 25:33.780 the only two things that you can create, 25:33.780 --> 25:36.420 like use as search keys, I use ID and username, 25:36.420 --> 25:38.980 but in the upcoming version, we extended this, 25:38.980 --> 25:41.420 like there's filtering by UID range, 25:41.820 --> 25:43.940 and there is a fuzzy name search, 25:43.940 --> 25:46.660 so that basically, yeah, we also look at the real name 25:46.660 --> 25:48.060 focusing like that. 25:48.060 --> 25:50.420 So, it's in there, you can search by disposition, 25:50.420 --> 25:51.180 and a couple of other things, 25:51.180 --> 25:52.340 there's aliases for user record. 25:52.340 --> 25:56.980 So, we do intend to make changes to the query API, 25:56.980 --> 25:58.820 but it's, I mean, everybody can implement 25:58.820 --> 26:00.260 whatever they want on their interface, 26:00.260 --> 26:03.740 that's true, but of course, it's only useful 26:03.740 --> 26:05.180 if this is generic, 26:05.180 --> 26:07.860 it's saying that it's actually part of our specification. 26:07.860 --> 26:10.580 So, while I would invite everybody 26:10.580 --> 26:13.980 to extend a JSON records with whatever the fuck they need, 26:13.980 --> 26:16.940 I would probably not recommend them to do this, 26:16.940 --> 26:18.340 interface the interface locally, 26:18.340 --> 26:21.940 because we are not gonna ask for this unless it's in the spec, right? 26:21.940 --> 26:24.300 Like, so the consumers of these records, 26:24.300 --> 26:26.300 the clients that actually talk to the IPC servers 26:26.300 --> 26:28.700 are probably not gonna use your extensions. 26:28.700 --> 26:30.980 Yeah, so, but I don't know, we are happy to extend this, right? 26:30.980 --> 26:33.100 Like, just let me know what else you need 26:34.100 --> 26:36.460 in the stuff like, for as a filters, or, 26:36.460 --> 26:37.660 like, once thing then, for example, 26:37.660 --> 26:41.020 I would like to add, soonishly, is that we're not only, 26:41.020 --> 26:43.540 we're a port information about actually existing users, 26:43.540 --> 26:46.620 but also about user allocation ranges, right? 26:46.620 --> 26:48.380 So, that, I don't know, 26:48.380 --> 26:51.060 the system these dynamic user ID stuff for services 26:51.060 --> 26:53.980 can basically report like which ranges are using, 26:53.980 --> 26:57.820 and then we can, like, this is interesting for allocation, 26:57.820 --> 27:00.060 like, for things like, container managers that just need 27:00.060 --> 27:02.900 to allocate a certain range of user IDs dynamically, 27:02.900 --> 27:04.460 that can take this information into account 27:04.460 --> 27:07.500 and then avoid the ranges that are, like, possessed 27:07.500 --> 27:11.660 by some component of the OS, of that answer to the question. 27:11.660 --> 27:14.660 So, I think we are actually having two things here. 27:14.660 --> 27:19.660 One is use of modeling as a means to communicate 27:20.220 --> 27:21.980 between applications. 27:21.980 --> 27:25.580 The other one is a specific use of modeling 27:25.580 --> 27:30.580 by system D to provide these user DB API endpoints. 27:31.500 --> 27:34.740 And I totally envisioned that there could be 27:34.740 --> 27:38.540 an other borrowing namespaces, right? 27:38.540 --> 27:42.260 Provided by the specific applications that consume 27:42.260 --> 27:45.660 and expose additional information. 27:45.660 --> 27:48.980 It may be not the multiplexer who would be collecting 27:48.980 --> 27:51.260 that information together from them, 27:51.260 --> 27:53.620 but certainly a different endpoints. 27:53.620 --> 27:57.020 So, yeah, I mean, people have asked us to do things 27:57.020 --> 27:59.220 like user record modification, right? 28:01.540 --> 28:03.380 I think, like, I mean, if there's actual demand 28:03.380 --> 28:04.940 about doing this, like having a generic way 28:04.940 --> 28:06.540 how to update the user records, 28:06.540 --> 28:09.620 we can look into doing this, but my assumption right now 28:09.620 --> 28:11.140 is that, in particular, the enterprise these stuff, 28:11.140 --> 28:13.620 it's rather unlikely that you would trigger 28:13.620 --> 28:16.180 the user record changes from the client machine. 28:16.180 --> 28:17.860 You probably would do that through some web 28:17.860 --> 28:18.940 things somewhere else, right? 28:18.940 --> 28:21.300 So, I don't know. 28:21.300 --> 28:23.100 We can certainly come up with an abstract interface 28:23.100 --> 28:25.060 to covering that, but I would probably make it separate 28:25.060 --> 28:27.580 from the regular user database, but I don't know. 28:27.580 --> 28:28.820 That's just details. 28:28.820 --> 28:33.300 But we can come up with anything, like, what user one there. 28:33.300 --> 28:34.100 There's a question. 28:40.100 --> 28:42.540 So, the question was, like, if I can say more 28:42.540 --> 28:47.220 about the details, how the SSH key integration works. 28:47.220 --> 28:51.460 So, you know, SSH D has this call-out thingy. 28:51.460 --> 28:52.820 What's it called? 28:52.820 --> 28:55.180 Pop key command or something, something weird. 28:55.180 --> 28:57.540 Like, this also has keys command or something. 28:57.540 --> 29:00.380 We implement one reference implementation, 29:00.380 --> 29:03.820 and then we just go to this and pick the data out of it. 29:03.820 --> 29:05.580 And it's enabled by default by system D. 29:05.580 --> 29:08.300 It's kind of annoying because they can only be one 29:08.300 --> 29:11.620 implementer of this, and SSH D, so that's a fight. 29:11.620 --> 29:15.380 So, I then, like, one way to address that fight, of course, 29:15.380 --> 29:19.140 is to just give me these records, and I will do it for you. 29:19.140 --> 29:20.980 I don't know, like, if that's not the cards, 29:20.980 --> 29:23.100 we can certainly make it so that we call first 29:23.100 --> 29:25.020 or, like, chain load other tools. 29:25.020 --> 29:27.140 But I, much rather, I actually see that people just 29:27.140 --> 29:28.340 give us the user records. 29:28.340 --> 29:31.020 Because, I mean, if SSH D or whatever else has this 29:31.020 --> 29:34.020 information, they implement this, and it was just, yeah. 29:34.020 --> 29:36.620 So, basically, the way I see it is that I would really 29:36.620 --> 29:40.260 prefer, if a thing like SSH D would just give us the data, 29:40.260 --> 29:43.500 and we do the integration with the rest of the work, 29:43.500 --> 29:47.700 like, lower level system stuff, then all of us trying 29:47.700 --> 29:50.940 to do this deep integration and fighting over priorities 29:50.940 --> 29:53.700 and fighting about who on SWATF there's a single thing 29:53.700 --> 29:57.780 that's, like, I have to make sense of it. 29:57.780 --> 30:01.500 Yeah, if you want to start working with welding, 30:01.500 --> 30:04.940 ISO, as a client, also, or as a server, and trying 30:04.940 --> 30:08.620 to understand it, you normally first used a welding 30:08.620 --> 30:09.980 CTL command. 30:09.980 --> 30:13.340 But there is absolutely no documentation how to actually 30:13.340 --> 30:16.980 use it to make these calls with the multi-plexe. 30:16.980 --> 30:19.780 It took me an hour to read through the source code 30:19.780 --> 30:25.740 to figure out how to just call it and get, like, a C, I mean. 30:25.740 --> 30:28.020 No, with the welding CTL command. 30:28.020 --> 30:29.620 Well, I'm just understanding it. 30:29.620 --> 30:30.820 Well, it's actually pretty easy. 30:30.820 --> 30:33.700 Well, I have the only introspection call there. 30:33.700 --> 30:36.580 But if you figure out how to do it, it's really easy. 30:36.580 --> 30:38.820 But it takes you an hour to read the source code 30:38.820 --> 30:39.540 to understand it. 30:39.540 --> 30:40.660 So it would be quick to understand. 30:40.660 --> 30:46.260 I mean, just examples how to, so the regarding documentation 30:46.260 --> 30:49.340 generally, we have these specifications up on this thing, 30:49.380 --> 30:51.580 where they, of course, mind times up, but anyway, 30:51.580 --> 30:52.700 there's documentation. 30:52.700 --> 30:53.580 You can read this. 30:53.580 --> 30:56.300 I'm pretty, you know, there's big holes of documentation. 30:56.300 --> 30:57.660 Like, first time I'm going to take a once you talk 30:57.660 --> 31:00.380 to about Varlink and the C API that we provide to do 31:00.380 --> 31:03.100 is the bigging Varlink, there's no documentation right now. 31:03.100 --> 31:05.100 It's relatively recently become a public thing. 31:05.100 --> 31:08.140 But so, like, if there's really some issues that you're seeing, 31:08.140 --> 31:10.940 it just ping us and we'll see if we can do something about this. 31:10.940 --> 31:12.140 But yeah.