 Does this work? All good? For the camera, so talk with your voice to the room. Okay. Hi, I'm Mananath Pataling. How much time do I actually have? You are 55 minutes. Wow, that's good. I want to get what you sound like. Excellent. So just to make this clear, if you have any questions, let's do that right away. Let's not wait until the end so that we can get a conversation happening here. I'm much more interested in leading the discussion into the direction that you wanted and much less into me actually covering all my slides because I know that I have too many slides anyway, and it's really about the discussion, not about the slides. Anyway, so yeah. Today I'm talking about re-inventing home directories. By the way, if any one of you has seen my talk about this very topic at All Systems Go or at DevCon, it's going to be the same thing. There's a huge queue there. If you have seen it already, it would be good to just leave and let me do it. You're not going to learn much new stuff. Anyway, apparently no one has seen it before. Okay. So yeah. What I'm going to talk about is Duller-Home. Right. As you know it, or TILA as you can even call it more briefly. Yeah. What is actually Duller-Home? Duller-Home is obviously directory as you know, right? But it's more than that. Like you always, for something to be a home directory, you also need a matching entry in Etsy PassWD, actually in Etsy Shadow and these kind of things. So it's currently, yeah, two things. Like it's a user account in Etsy PassWD and it's actually a home directory in Slash-Home. There are many problems that I've always seen with this idea. First of all, it needs a writable Etsy, right? Where writable Etsy, by that I mean that if you create a user, Etsy needs to be writable. I personally think we should go towards systems where Etsy is generally not writable, except if actually reconfiguration takes place. And I would claim that creating users and things like that changing users is not a configuration change, but it's more like a payload change, right? It's what you do with the system itself, like what you do on the top of the system, it's not reconfiguration how the system itself behaves. So yeah, I think that's kind of weird mix right now in Etsy between the actual state, which is if a user exists or not to me, and the configuration of the system, which is everything else that tends to be in Etsy. So another problem I always saw is that we have always have to on Unix propagate the UAD assignments between systems. If you have like an NFS LDAP setup, it's like madness to deal with that, right? Like because UAD range is relatively small, and hence we need to be very, very careful if the system can show up in some environment that the UAD is matched, because that's how we do access control and everything's messy. Yeah, in the world of like with LDAP and it was NIST before it and all these things, it's a major pain and with NFS to keep these UAD things in sync. I personally think for most cases, how people use computers these days, right? Like for example, how I use my laptop, this is kind of weird, right? Like because we do all this infrastructure for a propagating, but I think we shouldn't, right? Like I think it would be way better if the UAD would actually be an artifact of the local system, that only makes sense by binding some user record to the local system when we actually come up with UAD. That doesn't mean it has to be that way exclusively, it just means that I think we should go to that way where the UAD is more the local artifact and not something global that we are supposed to propagate that actually isn't global, because of course these fixed UAD assignments don't work outside of specific organizations. Another big problem that I see is that there's no encryption built into this, right? Like your home directory is generally not encrypted. You can't have encryption on the disk itself, like distributions tend to do full disk encryption or do the encryption of the home, but that's very distinct from the actual encryption of the home directory which doesn't generally exist. And that is weird because it has this, like if you do full description, I tend to use that on my laptop and most people probably here in the room also do the same thing. You have this weird thing that during bootup you actually query it for a password and that's the password that matters, right? Like that's the password that actually protects the data, but it's a system password and what the fuck's the system password? It's something like on Unix which was supposed to be a multi-user system, sharing passwords between multiple people is a very weird concept, right? So yeah, and then after you typed in that password where that actually mattered, you got to either authentication to GDM or where you'll get you whatever you wanna log into, where we ask for username and a password. And this password doesn't matter much, right? Like at that point the data is all unlocked, right? Like it's just about access control at that point anymore, and not about actually protecting the data. And this is really weird, right? Like first the important one that is like on a multi-user system makes not much philosophical like conceptual sense, and then the per user one which actually doesn't protect your data which just does access control and but it's the one that actually is inherently the multi-user stuff. So yeah, this kind of weird. Yeah, to be precise it's no user controlled encryption. Yeah, that's no, yeah exactly. I mean it's system controlled encryption, and it's not user controlled encryption. And that is like, I don't think we should do things this way, right? Like because yes, most of the time our laptops use single user systems, but I think still it should be, we should figure out how to encrypt the stuff, how to lock the stuff to the actual credentials you wanna lock them to. Right, like the system for example should be locked to the TPM. But your data should be locked to something that you control, your password, your UB key or something like that. Yeah, so I call that mismatching encryption. Right, you protect your data with it, but actually what you protect the data with is a system property, not a user property. There's also problem, no modern authentication mechanisms. By that I mean like we live in a world now where UB keys become a thing, but everything's bound still to one single password in Etsy PassWD. Now people have retrofitted UB keys into this, but it's always a little bit messy because it does not live in the actual user record. It's not part of Etsy PassWD, Etsy Shadow. It's part of something like a sidecar database, right? So the inherent user database design of Unix is around passwords and nothing else, right? So yeah, no modern authentication mechanisms. And we live in a world now where we probably want even more than UB keys and passwords. We probably want pattern authentication, face unlocking, fingerprint stuff, I don't care. But yeah, so we're kinda stuck in this world there which is very weird. It's also not extensible, right? And this is big one actually I think. Right now stuck past of UDs defines the same way as it was in 1985, right? It has these five fields. User name, user ID, group ID, real name, home directory and shell, okay, that's six. But it's beyond that, you don't get anything, right? You can't add a field there, it doesn't exist. People have of course always wanted to extend this. And they did, right? Like Etsy Shadow is like the first attempt to extend this, so they added like an encrypted password and they added some account meta information like how long is an account valid and things like that. But it's, yeah, many gain, I call them side card databases because they are managed independently of Etsy PassWD and carry additional information. These things get out of sync because, I mean, ad user for example doesn't care about, I don't know, the SSH key for example, because the SSH key like in your home directory, authorized keys file, that's a side card database, right? Like extending the user record in a way without actually having to get rid of the user record, right? So all these things then they get out of sync and they are messy and if you do resource limits, for example, you suddenly have a completely different configuration format, like PEMR limits.cont for these things. So which is inherently user information like how many resources you actually wanna give the user. But yeah, thank you side card databases here. Etsy Shadow is one. It counts damage like this GNOME thing that adds information about like a photo to the user and a couple of other things. That's like the perfect side card database because it actually takes the unique stuff and then the somewhat GNOME specific way tries to add all kinds of new and shit to it. There's Samba which maintains like a database for the CISID, the SID, which is like how Windows does user management. SSH has the SSH keys, PEMR limits does resource limits and things like that. And there's so much more than this. There's no resource management. Like the only resource management you get is PEMR limits. But what they said, like resource management are basically mean that yeah, if we actually have a multi-user system, right? You probably wanna assign a set of resources to specific users, right? Like because not all users are equal, the administrator probably should get more memory and see if he wants to or she wants to than a regular user. All right, so they're in a classic model. There's no resource management built in. The only resource management you get is PEMR limits and that's bullshit quite frankly. Because that resource limit is per process, right? So you can fork, you get a new set of resources fresh for free and then nobody will stop you from doing this. So how we actually wanna do resource management these days is we see groups, the kind of stuff that system manages. And we have nothing so far. So these are the problems I always saw. And it's kinda, yeah, if you start doing something like home dean, you figure out what do you actually wanna fix? This is the stuff we wanna fix. What we put the focus on is like, I mean, then you have to figure out what the focus actually, yeah, you wanna, who you actually want to use this stuff. The focus for home dean is human users, right? This is in contrast to system users like, I don't know, the user that you're a patchy demon runs under or things like that. So for home dean, I only care about human users, like me using that thing. In particular, laptop users, right? Like this is the world. On a laptop, you usually have one user, maybe you have two users, because your girlfriend uses two or boyfriend or whoever. But you're unlikely gonna have 1000 users on this one laptop, right? I mean, there's certainly environments which do that, but it's out of the scope for what I care about. So yeah, the amount of use you have on your laptop is below 10. It's kinda the focus. The goals that I wanna solve at the same way because I kinda like this is one of them, I'm not sure how much, how interesting this particular facet of this in real life, but I kinda found it a sexy idea, which is truly migratable home directories, right? All the way to the point of having a home on a stick. By home on a stick, I mean basically that you have a USB stick, and that this not only is where you store your home directory, but it is your home directory, meaning that you can plug it into this laptop today, log in and just works, and you can take it out and put it in another laptop tomorrow, log in there, and it all just works, right? So for me, migratable home directories means you have the actual data, but you also have the accounts information for that home record, all in one unified place, so they can just take it from this system into another system, right? So again, this USB stick thing, nice thing, and I'm pretty sure some security paranoid people will love this because it basically means you never leave actual payload data on the system while we are logged out because you just have it in your pocket and take it to the other device and only then you log in there. But in general, I'm pretty sure I personally wouldn't use this, I wanna store my data on my laptop because everything else is just, I don't know, I'm a lazy person, but it still is kind of useful that if I get a new laptop, I can just take this one file, which is my home directory and put it somewhere else and it's all in there. I don't have to reallocate the same UID and assign Etsy past WD in there and don't have to populate all this other side card databases so it all matches again with my old laptop. So that's a very stupid security question. Because we are bringing our home directory to some random machine, then how do we protect the home directory, we connect it to some malicious machine that someone has grouped account and can just open the content of our home directory? Even if it was encrypted, but at the time when we logged in, it was encrypted. So I'm not sure if I answered the question, but I'm supposed to repeat it, so the question was regarding how is this protected if you could copy it to some Roke machine that... So if you take a pen drive from one laptop to another one, which is untrusted, and there's some malicious software, so as soon as you log in and unlock the pen drive, it's encrypted. So the question is like, if you actually have your home directory on a pen drive and you move it from one machine to the other and you don't trust the other one, how does your data get prepared? It doesn't, right? The answer to this is, I mean, don't do that to untrust the system. So what's the point? I mean, what do you think? I mean, the point is really like, of course, you have to establish some level of trust between your home directory and the user, right? And we do this to some point. For example, when HomeD manages something, it signs the user records and makes sure that you have to have a signed record that actually has a key in the key ring that is on that specific system to do the other kind of protection. But inherently, the USB stick cannot, like it's a passive storage, right? Like it cannot enforce security policies on its own because it's not a computer. It's a storage device, right? So if the host has access to your credentials so that it can unlock your USB storage, right? If you were dumb enough to provide your password to that user, then it's freedom. Like the system can do whatever it wants, right? But the key of what I'm trying to design here really is that you have very clear life cycles that you basically say, when you're logged out, you're logged out. When you're logged in, you're logged in, right? And while you're logged in, you will get, or the system will get access to the device, but when you're logged out, it should not be possible to access your device, right? So that the moment where you decide to trust that machine, right, is the moment where you type in your password and only then the machine can access it. And then when you pull it out, it loses the ability to do this. But yes, do not plug this into untrusted machines. If you do, you're dumb, I'm sorry. So, yeah. The user and make sure that they are aware they cannot go just to the library and connect it to some random PC. Because so on, that's all my data, all my home directory. This talk is not about fixing the problem of untrusted computers, right? I think we should do this better. And there is like Chromebooks, for example, have a better model there, not a perfect model. But you can never have an entirely secure system because sure, we can lock things down in software and we should, but also, I don't know, I'm not capable of detecting a key law around my machine, like a physical one, right? So, I don't know, yeah. If you don't trust the machine, don't use it. But what I'm trying to get to here, right, is at least that it is very clearly defined like when data access is allowed and when it stops, right? So that, yeah, the only thing that the user has to do is like provide the password to the system and that actually truly unlocks access to it. So, yeah. Anyway, let's... 80% of your problems are solved with using ZFES already. So, why you never looked at it? For home directories in Chromebooks? I'm sorry. Snapshot is there, you can move to ARM, to Spark, to all of the architecture. Yeah, I don't think ZFES solves any of these problems. Like, first of all, like, again, home directories for me is something that is self-describing, right? Like, so you have the data store and you have the user recommended data. I don't think that ZFES does that. ZFES is a user manager that has, like, a user database in it. Is that your file system or your... Again, that's not what I'm saying. Anyway, let's have the discussion otherwise. I think this is, like, this is about user management. ZFES is not a user management dammit. It's a file system. And I'm not sure I have to have this discussion here about what the difference between a file system and user managers. So I'm sorry, but let's discuss it afterwards. Yeah, I mean, there's a general problem that configuration files are not always as stable as we wish them to be, but no, it's not in focus for this stuff. I mean, it's like, yeah, if apps break like this, it's nasty, but I think, you know, it's for the apps to fix. And it's... I don't think, I mean, the big thing that tends to break is usually the downgrade. Because app developers have an interest that stuff just continues to work as people update the stuff. But I think the problem becomes less of a problem as soon as we move to a model where software is always updated, because we have to move to that model for security reasons, right? And then this kind of is solved as a side effect, I think. Yeah, most of the problems with this won't have your stable release at work. Yeah, but it's... You always have to handle with that. It's kind of, you know, this is not a problem that is new to this model, right? It's a problem that you always had to deal with it, NFS, and these kind of things, right? But yes, you're expected to run the newest stuff in the world where we have security problems. And yeah. Anyway, let's go on with the slides for a moment. So yeah, the home directories shall be self-contained, right? Like the data shall not be distributed over the entire system. There shouldn't be an etsy-pass-w entry, etsy-shadow entry, and all this side card database. It should just be monopolized in one place. And that also means that the mere existence of the file home foobar.home synthesizes the user record, right? So you drop it in there, and that's a sufficient so that get and pass WD, like this Unix tool that allows you to, or Linux tool that allows you to animate all users, makes up, make sure that the user shows up, right? So, I mean, in a way, it's the most Unix-y thing you can do, everything's a file, right? Like it suddenly, the user becomes a file and in this self-contained. I kind of mentioned this already, but I want the UAD assignment to become a local artifact, right? Like so that at the moment where you log in, the UAD gets assigned and it's valid for this local system, but when you move the home directory to another system, then ideally you get the same UAD, but it actually doesn't really matter if it's taken there already, you get a different one. And we deal with this nicely. So, yeah, UADs become local artifacts. It doesn't mean they have to become that. If you actually want to have a fixed one, like to sell out, it's all supported, but at least it should be supported and it should be the default of behavior that people don't have to think about synchronizing UADs across the entire organization. This is kind of core of one of the SDS, that the unification between user password and encryption key. I kind of already indicated that earlier, that we have this current weird split where you have the password for the full disk encryption, which is actually the encryption key, and then you have the user password, which is distinct concept. I think this is wrong, should be the same thing. If I can decrypt a home directory, this is the same thing to me as authentication, and authentication would always be the ability to decrypt the home directory. So, that things actually are unified and people can actually understand this. Also, extensible user records, right? I talked so much about the SideCard database and how awful they are. Extensible user records basically mean that anyone can put anything in these user records. I don't have to care. We don't have to have a set of stone, set of fields, but the Samba people can, as I said, I don't know, the cavernous people can put their stuff in there and whoever wants to put more stuff can do this. It should be truly extensible and everybody can have their own fields, depending on whoever they wanna manage. Also, one important thing is like, we live in a world these days where full disk encryption is used, but also in a world where people don't turn off their computers anymore. I don't. I checked the uptime yesterday. It's like 50 days. I have not turned off my computer anymore. So, the way how full disk encryption works so far is always that, yeah, during British, apply the password and then it stays in memory all the 50 days that I've been using this computer. So, if you manage to steal my laptop and manage to access my memory, which is not as hard as you might think, you'll find my decryption keys in memory and can then decrypt all my data and that sucks. So, what should we do? We should make sure that when you suspend the machine, this stuff is erased from memory first, so that if somebody steals my laptop, I want it suspended, they still will not be able to access my laptop. It's really like as if you had a house and you would just put the key next to the door so that whoever wants to break in can just take the key and break in, right? So, fixing this, like Lux always had a concept of suspending access and just erasing the key so that this all works, but it was always extremely hard to implement in real life because if you do full disk encryption, the OS itself sits on the encrypted medium, right? So, if you want to re-request the password from the user when the system comes back from Resume, you need to ask the user for something, but it cannot be this OS itself because the OS itself sits on the encrypted medium, right? And that basically means that, yeah, if something's not paged in, you need to read from a hard disk, you cannot read from because you haven't supplied the password yet, but you are the one who is supposed to ask for the password so you deadlock and everything, shit. So, we need to come to a world where we can do this safely, meaning that the infrastructure that asks for the password needs to be separate from the stuff that we actually locked down where we flush out all the keys. Also, what is important to me is like, it's not all passwords anymore, right? Like in particular, I'm interested in PKCS 11 devices, like UB keys specifically, but also any kind of other device where we actually truly use them properly, right? Not for authentication, not just for authentication, but also for the encryption part, right? So that we use them as a smart card that they are and actually derives encryption keys for the Lux medium directly from the UB keys the correct way. So, yeah, it's kind of a key that, yeah, I don't know. I wanna be able to use UB keys at least and actually not just use them for, I don't know, it's not the indication that they're indicating to Google. I actually wanna use them to properly and securely protect my local system. So, a couple of complications with this. SSH logins is one of them. Like the problem is always like, if we lock this down properly so that unless you have provided your password there, it's impossible to access your data, you lose SSH logins to some point, right? Because SSH, you know how it works, right? Like it reads the authorized keys file from your home directory. So before you locked in, how is it supposed to do that if the home directory is encrypted and you can only decrypt it after you authenticate it? That thing is solvable and we solve it to some point because we're actually able to embed the authorized key stuff into the user record, which is available before you actually mount it. But then you still have the problem, somewhere, if you log in for the first time, the password needs to be supplied, right? Like, authentication via SSH keys, like how people use SSH means basically there's never a password actually exchanged, but we need that password to unlock the disk. In an ideal world, we could just fix it so that when you log in, first SSH does its own authentication and we would then simply ask the user, hey, please provide the actual password so I can decrypt the hard disk for you. Fortunately, the way SSH and Pam and these things work, we can't really do this. It's not a big problem. I know in the previous times I did this talk, people really, really hung themselves up on this issue. I don't think it's much of a big problem, right? First of all, it's about laptops. It's the stuff you log in with SSH out of. It's not the stuff you typically log in. If you do, you do it for emergency purposes and I can live with that to some point. Also, you can always do the same way, log into some other account that doesn't have these kind of protections and then locally provide the password to unlock it like there's a command for that and just log out and then log in really because as soon as it's unlocked once, the SSH works as it always worked because then the password is applied and then the home directory is mounted and everything's good. Just to make sure that we're on the contact, you mentioned that SSH keys are not part of the user records or anything, which means that they reside in plain text on the pendrive, right? No. No? Okay. So the question was regarding what about these SSH authorized keys? If they are part of the user record, do they reside unencrypted on the pendrive? No, they don't. If you actually, again, don't hang yourself up on the pendrive. I made that as an example, but I don't want you to think that home directory is on pendrive. You can do that, but let's forget about the pendrive thing. But no, we of course made sure that this doesn't happen. So the user record is actually stored three times per pendrive or loopback file. Once inside of the home directory, which is encrypted, once in an encrypted form in the lux header, which is entirely redundant. The only reason we do this is mostly because the kernel file system people made very clear that they are not interested in making sure that images, like file system images that you have that are rogue cannot exploit the kernel when you mount them, right? Like there is no fuzzing and these things taking place so that you can have rogue file system and the kernel doesn't fuck up if it actually acts as some. So that basically means we always need to establish trust first, to some point at least, before we mount it, right? And the way we do this is by decrypting first that user record that is on the USB stick, verifying that it's properly signed, that it's a user record that's actually supposed to log in. And only then we go into mounting, so that the minimal level of authentication is established. But anyway, this user record is encrypted. Like the first one. And then there's the third one, which is actually copied onto the host the first time you log in, right? Because we still have to pin your user ID so that every time you come back you get the same user ID. That's important because the way Unix works if you have a file in some writeable directory somewhere, we cannot recycle the UAD right now. It's something we also wanna fix with sandboxing but it's a separate story independent of this one. But anyway, so yeah, you basically end up with three copies. A two on the stick, one on the system. And yeah, we carefully make sure that when you lose your USB stick on the street, somebody else picks it up, that the only information that is actually leaked to that user is your username, right? Like because we need that because if we stick it in then you have to still type something into your getty prompt or something. And then provide the password. And the password is when you provide it for the first time is actually the thing that unlocks the user record. Because again, as talked for earlier, we need to define clearly the point in time where this trust is established, where you provide the password to tell the system it's okay now, you may have access, I trust you. Disc space assignments. So with HomeD, like the way I like, HomeD is actually something that has five different back ends. The backend that I try to push people towards is the Lux backend where you basically either have your USB stick or you have a loopback file and slash home where everything is stored internally. But there are actually a couple of other back ends, like there's one for FSCrypt, which is like XD for online, like the encryption that is above the file system layer. There is also a couple of others, like plain directories, even if you don't care about encryption. But yeah, the one that I actually think that people should be using is the Lux one because it has the strongest security properties and allows you to do these things like raising the keys for memory when you suspend and more things. But it comes at an interesting behavior, which is disk space assignment. If we have a loopback file for every user and slash home, then it basically means, yeah, there's just like how you size that loopback file basically means how much data that user can store. Traditionally in Unix, we always said that, yeah, on my laptop if I have five users, all of them can fill up slash home as they want. They all fight for the viable disk space and the one who is lucky is lucky and the one who isn't lucky is not lucky, right? With disk space assignment with loopback files, you of course have to size the stuff a priori. We can resize online all the time. That's great, but that's exposed and homely. But you still have to, yeah, you basically get committed disk space assignments and if you think about it in a simple way, they cannot overlap, right? So that basically you lose the over commit functionality that how user management traditionally worked where you basically would say, yeah, even if you use you quota, you could say I have a one gigabyte disk but I give everybody two gigabytes of it, which made no sense, but you could do this kind of how we did this thing, right? So I don't think that's much of a problem because we have these nice behavior in Home D where you can do stuff like, you know, sparse files and discard. Like in Unix, we have this concept of sparse files where basically if you have a large file and it has zeros in it, you don't actually have to allocate space for these zeros, but you can just let the file system deal with it and tell it that this is empty space. You're not supposed to store it. Just when I read it, give me empty space, like zeros back. So, and we can use it all across the stack like that the loopback device does that and the file system device does that. And in Home D, we have this automatism that when you log in, we actually have allocate stuff for you so that actually this white space is removed. That basically means that while you're logged in, you get these guarantees that the one gigabyte you got assigned is actually what you get assigned. But when you log out, we tell basically the kernel to remove all the holes again, return it basically to the underlying file system so that somebody else will then logs in and can use them. The effect of this is, yeah, we give you guarantees that when you log in and you are assigned one gigabyte, you get the one gigabyte and nobody can take that away from you. If you're logged out, everything is shrunk to the actual space that you need. And other people can use it space. So, yes, just to answer because assignment becomes a little bit more complex, but it's actually, I think, very nicely manageable as long as you don't assume that you want multiple users to use your laptop at the same time. I'm not sure how that even would work because I only have one screen, one keyboard, but sure. So, yeah. There's also the problem of UAD assignments. And it sucks a bit. Like, because as I mentioned, I want that the UADs become artifact of the local system. And if they become artifact of the local system, we have to pick a UAD at the first login and assign it to that user that is not used on that specific system yet. But that is sucks because then all the files in the home directory will be owned by wherever this stuff was mounted earlier where it got a possibly different UAD. What do we deal with this? Ideally, we would just tell the kernel, mount this stuff and make all files owned by this UAD. Unfortunately, the kernel currently doesn't have that. Hopefully, eventually it does. So what do we do? We do recursive chone. Meaning that, like, when you log in and the U does matter, we just actually go to the file system and chone all the files. Sucks. Don't suck as much as you might think because actually chone recursively on modern file systems is ridiculously fast. We're optimized for this kind of thing that dentry lookups are cheap. And so it's not as slow as you might think. Like, at least on my home directory with, I don't know, 500 gigabytes or something or more, it takes like two seconds if the UAD actually changes. Yeah, this comes up all the time. We can use the username space for that but actually I don't think we want to. Username space basically means that you have to have a sandbox around the user because he has to live in that or he has to live in it in that namespace. But that sucks because as soon as you do sandboxing, you basically lose privileges in the system. You live in your own little world. People have done this before, particularly for file system namespace and I'm pretty sure we should go that way eventually. But it also means that, yeah, weird things happen because if you do these kind of mountain namespaces, then you see the system in a completely different way than you would traditionally do. With HomeD, I didn't want to go to that step yet, right? Like I think we should have sandboxing but also this is inherently supposed to be something that I want to use on my laptop, right? And if my user can't see the system anymore the way it is, then I'm going to have a very hard time with debugging that stuff. But you're absolutely right. Eventually we should have sandboxing and I don't know if I built a laptop like this and give that to my mother. She has no need to see all the processes owned by the correct users. So for her, we definitely want the sandboxing to work. Yeah, Lux Locking, I've already talked about this, like about the stuff that, yeah, I mean, so as mentioned, HomeD does this thing where when you suspend the system, all the crypto keys that actually used for Lux stuff is removed from memory. But then we have a problem that when the system comes back again, we have to provide the passwords again so that it can actually use your home directory. The way we address this right now is we don't. We have this requirement, basically, that after you come back from Resume, there's some kind of authentication taking place where we can read the password again from the user and user to unlock stuff. The way I think of this should work in the end of it, if you were, for example, if you use GNOME, that right now you get, when the system resumes again, you get this lock screen where you're supposed to re-authenticate, but this password always stays with the GNOME. And I think it's, yeah, and it runs, like this password prompt runs under the user ID of the user itself, which I think is problematic anyway, but that approach doesn't really work anymore because after all, if we come back from Resume, everything that is in the home directory and that accesses the home directory is gonna be suspended because we remove the key so that it can't actually read or write from that home directory. So what we do need to do there is that instead of doing the screen lock from the user's own session, we need to switch back to GDM or something to the display manager to some privileged component that asks for username and password. Then, when you provide the password, we can use it to unlock everything and then you can switch back. So this is a little bit of a complication, but to talk to the GNOME people, I think they're very much on board with making this work. As long as we don't have that, you can even just do switch to a GEDI, do a quick log in, log out again, and. What kind of design of the plain media where you're locked to? Sorry? Like plain media where you're locked to access to some data you want. For example, GDM, GNOME challenge, you can play your media, right? You're locked if you want to do that. Like media playing. Media, like your music playing. Well, I mean, it's like this stuff is supposed to be secure, right? Like so that you get this guarantee that when you're not sitting in front of the computer and have provided the password when you started using it, that nothing can access your home directory, right? Like the security guarantee that I want to give you because I think it's a good security guarantee. This does conflict if people want to do stuff with, for example, that I don't know, you get email notifications when you're not locked in and things like that, or that you can play music while you're not locked in. But yeah, that is fine even, right? Like in that case, don't suspend the machine. I mean, you wouldn't suspend the machine anyway, would you? Like, I mean, because then the music would stop playing too. Okay, so that's all you're supposed to do now. So. Yeah, I want to expand on that. Like I'm sending a big file to the server, waiting two hours. I'm going away because I need some coffee. I'm not going to sit. I'm going to log out. Well then, I'm losing access. And my download is not continuing? Yes. I mean, I will give you the guarantee. So the question was regarding what happens if I do a long term, like a long download. And you traditionally, this person here solved it like logging actually out and making sure that the download continues in the background. What does happen if this is used? Yeah, I'll give you the guarantee when you're not in front of the computer, your data is not accessed by the system, right? And this basically means the conflicts with that stuff. But, you know, you can like, this is like, you know, this lingering concept of log-in-D. It basically allows you to say, yeah, leave this stuff around from this user when you're logged out. You can just turn this on, but that basically means you lose this nice property because that means the crypt keys need to stay in memory as long as your stuff logs out even if you're not sitting in front of the computer. So yes, you can do this. I don't think that it's nice semantics though, right? I'm pretty sure that at least on my laptop, I want to know that when I leave this stuff, that I know that nothing there can access my memory, that I don't know, everybody can steal my laptop and still not get access to my memory. This is a much nicer property that I want to deliver to people than, yeah, being able to finish downloads while I'm logged in. So yeah, I mean, this is conflicting stuff, right? I know like, I mean, we take away to some point cron jobs for you as well, right? Because cron jobs traditionally have this thing where they would run even when you're not logged in, right? In this model, it doesn't work, right? Like if you run stuff as unprivileged user while you're not logged in, somebody has to provide the password. And if you don't, because you had less cron job, then no way, you don't get to good do this, right? But this is entirely up to you, you know? If you subscribed into this model, like actually using Home D and getting the security ideas, you lose the property of being able to use your home directory with self-sindication. But then, if that is important to you, probably shouldn't use Home D or like, I mean, there's something we can probably do is that if you turn on this lingering thing that I mentioned, right? And that basically also means that we can basically set up the user context during boot instead of during login, right? So we could actually say, if you set up things like that and we need the password to actually work, that we ask you during boot. Like we always did full-fooled encryption for the password, so you log in once at that point. But this is not implemented. This is something that's relatively easy to do, but we don't do that right now. But I don't know, it's kind of outside of the model I want to go to, right? I want this lockdown secure thing. And that is like for me means that if I'm not at my laptop, nobody, nothing should get access to my data. How much time do you actually still have? 17 minutes. 17 minutes. So, actual implementation. I talked a lot about the stuff that I want to do with this. Now let's actually talk about how this translates to code. In SystemD, we added two concepts and all the last stuff was actually merged two days ago. One is JSON user records. JSON user records, like with all the stuff I talked about, locks and the actual home D stuff is kind of independent of this. Like the first thing I want to deliver is JSON user records. So basically is that, yeah, a struct past WD, you kind of have that in JSON now and it's fully extensible. And you can denote lots and lots of different properties. In SystemD, if you provide these JSON user records, we'll actually do resource management for you, couple of security things for you, couple of, like actually run other runtime parameters for you. But we can agree on some form of more modern way of talking about users. These JSON user records are not bound to home D. Like home D is one component that then makes use of this, but actually anyone can supply them, like anyone who's privileged on your system can provide additional JSON user records. And we just had this conference, this DEF conference in Czech Republic, like where I talked to all the rat head people who do LDAP in these things. And we're mostly on the same page that, yeah, they're gonna supply from SSSD and this LDAP stuff. User records are the same format so that for the first time, they can, from the LDAP database, actually do proper user management, security management, that all the way propagates down to the system and SystemD enforces it. So, yeah, this is concept A, as mentioned, independent of home D. You don't have to buy into home D to maybe be able to make use of this. It's a superset of NSS records, so it's struck past WD and struck group and actually all the shadow ones and extensible. There's a var link interface, var link is some IPC system to query this and it's extremely dumb and simple. And the idea basically is that anyone, like any component that wants to provide a local user can just implement that var link interface once. And then clients can just ask them all at the same time and query those users. It's convertible forth and back to an NSS. Lossy, of course, because NSS records, like by NSS records, I mean, like struck past WD and struck group, go there, of course, don't have all the metadata, but SystemD will do all the conversion for you. So, it's up to you if you just wanna supply the classic NSS stuff, like most components currently do, then we'll generate JSON stuff on the fly, but the other way we'll also do it. Like, if you only supply the JSON stuff, then we'll generate NSS stuff for you if you want that. How does it actually look like? Here's an example, it's kinda complicated. Some things are pretty obvious, like username, like this user's called grovey, and I don't know, nice level means that when the user logs in, he gets a nice level of five. This member of is about groups, that this user's supposed to be a group, a member of the group wheel. Last change, usec, I guess I don't have to explain what that probably means. There's a concept of certain subsections, like the binding one is actually the one that maps a user record onto the local system, right? Like because a user record is something that I think should be independent of the local system, but some of it feels inherently, like for example, the user ID, like this one here, actually inherently have to have a local concept if we wanna do this thing, where we say that UIDs should be a local artifact. So, a binding is supposed to manage this, binding is basically yeah, this is the machine ID of the specific system, and then you store a couple of metadata specific on that specific system to it. I don't wanna go into too much detail about this specification upwards, if you wanna know all this, just to see that like privilege is basically where the hash password is like as a shadow. We put that in a separate section so that we can hide it from clients as they shall not have access. There's signature, which is like the cryptographic signature that I mentioned, how you can make sure that on a specific system only for example, users signed by the right-hand key can log in and answer systems not. Very good question. So, the question was regarding if user names have to be unique on specific systems? Yes, they do, because Unix works that way. But that basically, like so, I added a concept called a realm there, it's a little bit more of like a cover system realm, but it's also like domain, I didn't wanna define that any further. But the idea basically is that I can have user lennard at redhat.com and can distinguish it from a user lennard at, I don't know, Berlin, the EU, something like this, because they have a different suffix. But once you log in on that specific system, only one user lennard can exist, right? So it's a bit nasty that this is how Unix works and we can't really fix that. But I think it's probably in real life not that bad because on my laptop I'm probably not gonna have multiple lennards that are actually different. So that was the first thing, user records and JSON. Second thing is concept B. That's actually the homely part about it. So we have encrypted luxe home directors and loopback files, the stuff that I was talking about so long. I've mentioned that we have one file per user, like slash home foobar.home is a loopback file, a gigabyte in size, inside of that you have a lock stuff, you can actually mount that thing just with regular tools like you always did because it's just that, right? Like it's not the reinvention of stuff, it's just using stuff we already have and augmenting it slightly bit so that it's useful for user records. And yeah, if you mount it you find the JSON record, like the actual user record inside of identity there. But yeah, it's managed by the new service called system B home B. You can accept this and use it or if you don't have to, it's like entirely one provider of that user DB stuff but it's just one provider. If you don't wanna use it, don't use it, right? Like there can be others. So for example, if you're really, really bought into the LDAP concept that you have everything centralized and machine's kind of part of an organization if you so will, then you can soon hopefully use the user DB stuff but not use home D. Like home D is really about the use case where you have relatively migratable, independent of the laptops. I have a user directory here and I can migrate it to another one. It's all just works. Yeah, concept A, user DB records is independent of concept B in one way, right? Like you can use A without B but B implies A. Yeah, integration with the West, a couple of other components but I don't wanna go into much detail here unless you have no further questions because I think we have only 10 minutes left or something. So let's focus on questions. Sorry, what do you mean? I don't get it. How do you discourage us or even prohibits to just lock the screen but do not log out? No, it doesn't. No. How do you repeat the question? So the question was regarding if, as you understood, at home D prohibits locking the screen without actually logging out. But that's not true. No. Screen logging, screen logging. But screen logging means to me, that's the keys are left over there. Like you can, if you want to, turn this into something where you say basic screen log also means we flush out the keys. That basically means, yes, everything stops running. But we are not there yet. This is something we can think about but I'm not sure if you want this but if we do this, then it should be an option. But no, this does not imply this. This is something to think about that we might do later but no implication though. The idea is that you can migrate your home directly from your machine. What is the frequency of plan to do that? Is that a bare option? It just works. I personally work every day with two computers and I would like to carry a pen drive. Is that something that is just done in a minute that I can somehow do that? And if there are several versions of that thing there may be many unique backups. How do you do the versioning and what happens if I start using an overword and then I go to the new overword? Okay. So the question was regarding synchronization, right? Like if you have multiple users, you have the same user on multiple machines. Like how do we solve this? We don't. Right? So this is not a synchronization tool, right? Like I think having a synchronization tool would be extremely interesting. But it's, and I think this can actually be really nice because like, I mean, as soon as you have your home directory in one unified file, you can do stuff like actually distributing it to other systems in encrypted fashion without actually the distributing thing, actually knowing what it actually distributes there. You can do backups even like because you can do reflink, like because it's one file, you just do a CP with a reflink, you pay for nothing, you have a backup of that day and things like that. So I think the synchronization problem is a very interesting one and we should look into this eventually, but this one is not gonna solve this. And in particular, it's not gonna deal with deltas for you, right? Like with diffs between what you did on this laptop and what you did on this laptop because that is inherently something that needs to live above. Like if you actually wanna do proper diffs above the file system, above the encryption, because I mean doing diffs on encrypted stuff isn't really possible. So I think a very interesting problem, not gonna be solved by this, but I think it enables some things that we can make distributed stuff like this work. Like for example, that I don't know, if you are connected with a network that we just make sure that you're only locked in once everywhere and then whenever you log into something that your stuff migrate somewhere. I mean, you can even do stuff like for example, you can have your home directory on an iSCSI volume or NBD volume or something like this which is available to not your entire network, right? Because this stuff is just a fucking block device. It basically means that, yeah, if it's just there, it's gonna pop up as a user and then you look at any machine you like and you know that it's always shared because you always write to the same thing. We have no infrastructure for locking in this case, so don't actually do this, but it's certainly an idea. Like it opens a lot of doors where you can do stuff like that. But yeah, syncing is not solved right now and I think it's very, like the other problem with syncing is like, people disagree with what they actually wanna have synced. Some people want just the configuration, some people want the entire home directory. I have no nice answer to this. I know people have been looking into doing some syncing stuff. I don't know why this goes, but yeah, we have to figure that out. Groups with the same name, with your first design, you can define a user with some groups, but if you have common groups, but with different ones, what's happened? With different, what? With different? You can have the same groups, but on both systems could be different. So the question was regarding what happens if the groups that define differently on multiple systems, but you have one user that is accessing both of these systems. So first of all, you saw the JSON stuff, right? Like there's actually one section in there that's called per machine, where you can have static data that you configure and you can configure different, like from some of these settings, you can define per machine settings. So you could basically say, yeah, if on this laptop, the group foobar is something completely conceptually different than the same named group foobar on some other system, then you can basically say, yeah, on this one, I want to be a member of that, on that one, I don't, right? So first of all, that's one thing. Ultimately, the rule, though, is we allow access to anyone who has a user record that is signed by some key that is recognized by the local system, right? The entity that signs that really needs to take care of this problem, right? So I'm not going to solve this problem that if you have equally named stuff on different systems for you, that's the person who puts together the user record for you, who needs to deal with these problems and then maybe create per machine stuff or do something else so that this problem is fixed. Well, I mean, I'm not a standards organizer. So what's the state of the standard for the JSON user records? I'm not a standards organization. I mean, I kinda am, but also I'm not. Let me show you. Yeah, there's lots of interesting stuff in the slides, by the way. That's where the standard is. So if you go to this one, this is where the current JSON stuff is documented for the users, this is for the groups. This is for the vialing API to query it, and this is what we, it documents what we do if we use the lux home directory stuff, if you use that back end. Yeah, ours is extensible, right? And it's extensible in that fashion where you're not supposed to even talk to me if you want your own field, just take it, just namespace it properly, right? I'm not interested in being like this person in the middle who manages everybody's fields that's explicitly not what I want. Just pick a field you want, namespace it properly by just using a name that's unlikely collide with everybody else's and then add whatever you like. And then distribute it like Linux's, right? So, yeah. We talk about security. Is there a spread model on D because for me it resembles finger D. It resembles what? It resembles finger D. Finger D? Yeah. Okay. I think we should give access to the own directories. So I don't really understand the question, but if we did this spread model of this kind of stuff and because it resembles finger D, I don't understand why this would resemble... Maybe I would give access to other people to draw on that project to show which projects you have and which was followed with design. I mean, I know what finger is, but I don't see the relation to this. Finger is not about user records, and it's not about... I mean, again, this stuff is... If we put it in the home directory, that stuff is encrypted, right? We don't leak information. Unless you're logged in, nobody gets access to this. So it's actually only accessible to people who have access to the system. They can query the user database because that's how Unix always worked. But at that point, you also already have to have access to the local system. So I don't know if you want to implement something like finger D on top of this, you can use this stuff, but I don't see the relationship to finger D at all, I must say. Do you see the access to the home directory just like on DDesk? I don't see that, I'm sorry. How do I share a file? So the question was regarding how do I share files between two users? Well, you know, after both of them logged in, the users are not very distinct from traditional users, right? Like they'll both have a UID that's going to be sticky until the system goes eventually. Or they'll log out of each separate file? No, no, no, no. I do that when you do it on a different machine where the UID is actually different, right? So the question regarding like if you log out and log in again, what happens to the UID? Do we actually change it so that sharing files is difficult? So like first of all, you know, if you want to give other users access to your home directory, right? Knock yourself out. But also it's maybe not the best way to share files, right? So ultimately, like on a specific system, after you logged in once, we actually copy the user record onto the system so that it stays pinned and the UID assignment stays pinned. So that basically means that after you logged in once on a specific system, UID is guaranteed to be stable forever, right? We can only remove that limitation if we do the sandboxing stuff that we talked about earlier here, right? Because we need to make sure that you don't get to write anywhere else. But that basically means, yeah, if you want to use ACLs or to mod or tone or whatever else to give other people access to your files, same way as it always worked. Except if you then take that home directory and move it to a different machine, because if you do that, then you get the choning done. But that also means that we'll strip all the ACLs for you. Because, I mean, we have to because all the UID assignments and things like that don't make sense anymore. If you then move it back to your system, you'll get back the UID that you had before, but you'll not get the ACLs back because we had to strip them all. But my answer is if you subscribe to that traditional model, knock yourself out, but then you don't get to get the truly migratable stuff. It's one or the other up to you. So are we going to have any, I would say? So the question, I mean, my time's over, but let's do this one last thing. The question is like, will we have a shared folder where you can actually share stuff between users? I mean, you can't do this. Homie doesn't do this for you. I don't think, like, you know, I'm pretty sure that in most cases when you want to share something with other people, we probably do it via, I don't know, telegram or email or something like this because inherently it means probably most of the people who want to share stuff are not going to use the same system. Like, at least, when I have shared a file with somebody else in the last two years, 20 years, they didn't have access to my local system, right? So I think the focus for sharing stuff should always be on doing a distributed, right? Meaning do it on the network and not on the local stuff. But again, write that infrastructure if you want this. It's totally doable to do already. Yeah. I think that's it. I don't have any further time. Thank you very much for your interest and for the questions. If you have any further questions, let's do that outside.