 Hi, I'm Leonard Pottering, and I'm going to take away your home directories now. I'm a bit sick, so I hope I'm not going to lose my voice in the middle of this talk, but I'm talking about something that has not been versioned to system.ly yet, but hopefully will, and it's about reinventing home directories as the title says, because I mean, reinvention is what we do with system.ly, right? Anyway, I think I have good reasons for this stuff, and I hope to explain why, and I hope to also explain what precisely I have in mind that we do. So, what am I talking about? I'm talking really about your home directories, right? Dollar Home or Tilda, whatever you want to call it. It's that stuff that is paired with an entry in Etsy PassWD, and makes up your user record and your user dataset, if you so will. After working with Linux and Unix for a long time, I came to see quite a few problems with the approach we so far had. I'm pretty sure everyone of you knows how this works, right? I saw a couple of problems with this. First of all, the way we currently manage user directories in Linux is basically it requires a writable Etsy to create a user, right? So far, we always have this goal that if a system's configuration is not supposed to change, Etsy should be immutable ideally even, and hence the requirement that if a user is created, removed, or modified, or whatever, you need a writable Etsy kind of sucks, because a user's existence is not really configuration, at least in my view, right? So, the concept that mixes state, I believe that the user record is state, it's not configuration, and the rest in Etsy is generally understood to be configuration in this way. So there's this semantical, this philosophical problem already that, yeah, Etsy makes a state in configuration, and then this propagates into the problem that Etsy needs to be writable. There's also this problem with Etsy PassWD and home management, that user ID assignments on Unix need to be propagated between systems, right? There is a lot of infrastructure in this world for LDAP databases, how user records are distributed among many systems, how NFS has user ID translation, diamonds, and whatnot, because, yeah, everything is bound to user IDs, like numeric Unix user IDs, like these 32-bit values where zero means root, and the meanings of those in context of Unix network file systems always need to be propagated between systems, and that to me sounds so backward, because it basically means that every system you have only exists within a very specific institution, like organization, because only within that very specific institution and organization you can say that user Leonard has numeric user ID 555556 or something, right? So, yeah, I think the classic model worked as long as you had few systems, right? And created, like as soon as people tried to scale it to more systems, they came up with this massive complexity that is LDAP and things like that, and they end up managing this user ID that nobody actually really cares about, which is just an artifact of the implementation, and there's nothing something people should really care about. And in a world of today where we scale to the Internet, right, user IDs are complete in artifact of the 1970s, right? Like if I have a Google account or Facebook account or whatever account on the Internet, there's no user ID assigned to it because it makes no sense, nobody wants that, right? I mean, there are reasons why user accounts have user names, there are reasons why they have passwords, but the reasons for them having a numeric user ID on a specific system are a little bit weird. So, yeah, I see that as a problem. There's another problem. This model means the way we deploy it right now, no encryption, right? Home is generally not encrypted by anything that is directly related to the user, right? Slash home, like you might have full disk encryption, right? You might have encryption of slash home as a whole, right? But this is system-wide, if you will. It's not specific to the user, and that's weird, right? Like, because right now, like at least on my laptop, the way I installed it in Fedora, like a couple of years ago, I got the full disk encryption, so I boot up, I type in a password. That is my password, but also it's not my password because it's actually my laptop's password, right? Then I authenticate against my system. That decrypts the hard disk. Now, this is the password that actually matters, right? And after it booted up, I have to re-authenticate a second time into my actual user account, and that password doesn't really matter that much because at that point, all the data of the home directory is already fully available to anything on the system that ever wants to see this. So, I see there is this really weird discrepancy, like this mismatching encryption that we protect, like the stuff that's actually associated with user account is not what protects your data. It's the other stuff that protects your data that is system-wide, that if we actually had multiple user systems, like where multiple users use the same machine, where they would have to share that password, that makes no sense. The only way why we so far got away with this is because most laptops are single user systems, effectively, even though Unix and Concept can support more. So, I think this is the stems from... Yeah, nobody wanted to touch the way how Unix user management worked, and so we came to the discrepancy and we got away with it because we effectively are single user systems. I also see the problem... Yeah, Etsy, past WD only knows Unix passwords, right? Passwords, as you know them, it doesn't know anything else, right? Everything else how you might want to authenticate these days, whatever else, cannot be an Etsy past WD because it's not extensible, right? So anything more modern, anything... If you even want to authenticate with a pattern, right, like which is what phones do and which you might want to do on your laptop too if you have a touchscreen, it doesn't really fit into that model because, yeah, there's no way how that's available there. It's not extensible. This is actually a massive problem, right? Like, Etsy past WD, this database was designed in 1985 or something like this, has not been modified once since then. There has been this extension, like the shadow database, which added, like, five more fields or something like this, but everybody wants to add their own fields. And this is, like, this is, like, fucking ugly, if you ask me, because they created these sidecar databases, right? These databases that extend the user record, but they're not actually stored in Etsy past WD in the user database itself, but at some other place. And that other place means something very different regarding where you're looking. So, for example, Etsy shadow was the first sidecar database that was introduced, and it contains information about the actual password used and, like, account, like, validity restrictions, things like that. But then accounts demo is like this gnome thing. They wanted to add a picture for each user, so they have a sidecar database for that and a couple of other things. Samba has one because they wanted to have a GUID, so they created their own one. It's also somewhere in VAR. There's SSH, which wanted to have the authentication key, right? Like, the authorized keys thing in your home directory, right? Which is part of the user identity. It's how you authenticate. It's like your password in many ways. But, no, we can't put it in the password file because it's not extensible, so we put it in the home directory. And then, yeah, SSR tries to read from that, and it's highly problematic because, yeah, you have a privileged demo that goes into the unproved user directory and it's dangerous as shit. So then we have PAM limits, which is about resource management, right? Like, people want to be able to set limits on specific users. They want to make sure that some users can have more presence than others. The way they do it is they came up with their own configuration file, which is not even a database, but a configuration file in EtsySecurityLimits.com for something like this. So, yeah, we ended up with this... Yeah, simply because it's not extensible, we ended up with a distributed thing that you can't even manage centrally. Like, even if you use LDAP and try to manage this centrally, it usually covers, like, a fraction of this. Usually, the Unix records, maybe the Shadow stuff. But then as soon as you go into, like, sharing pictures of users with LDAP, that's, yeah, that's strange territory. Yeah, this is kind of the same thing. There's no resource management doable with EtsyPastWD. And I think resource management matters a lot, right? Like, because not all users are equal. So, you want to be able to assign specific resources, memory, disk space, whatever else to users. And, yeah, EtsyPastWD can't explain this. Then they create another secondary database for this, which is a quoted database on disk. But, yeah. So, resource management is, as soon as you think about multiple users, you also want to think about the differences between multiple users and how many resources you assign to each. But we can't really do this with EtsyPastWD, except through this mess of sidecar databases. So, this is, yeah, so far, like, a number of the problem. They think they're a lot more. This is kind of the problems that I saw that I wanted to fix with what I'm talking about here. So, let's talk a little bit about the focus of what I'm suggesting here. First of all, it's only about human users, right? I don't care about system users in this context, right? Like, system users being the stuff that demons run under. This is about human users, like me and you, right? The stuff that you have on a laptop. It's not the stuff that you have on a server so much. The goals that I want to be able to deliver with what I'm talking about here is, first of all, migratable home directories, right? Migratable home directories means that you can take a home directory, add one unit from this laptop to your new laptop or to your third laptop, and it will always work and be self-consistent in itself and comprehensive and hence migratable, right? So, this basically means that as little as necessary should leak into the system surrounding it, and particularly when it comes to configuration, which is very different from what was there before, right? Like, before home directories' user accounts were not migratable, right? Because, as mentioned, we have all these sidecar databases and there's no way you can sensibly migrate all that metadata that is distributed in all these configuration files in Etsy with the sidecar database and VAR and whatnot from one system to another. I want to go to this way where home directories are... Yeah, somebody didn't turn off his phone. I wanted to go... I want this to go to the way where they're truly migratable, right? Like, all the way to the point where you have a USB stick like this one and that this can be a home directory and you plug it into my laptop and then kind of work there and I can take it out and put it into another laptop and work there, but that this USB stick actually is my user account, that it is my home directory and it's truly and natively migratable without any magic bullshit of propagating configuration into the system, right? So it's about isolation. It's about unification, everything into the home directory itself and cleaning this up. I already mentioned this a bit. It's about self-contained home directories, right? So right now, as mentioned, if you want to have a user account, you have files everywhere. You have files in Etsy PassWD in entry. You have an entry in Etsy Shadow. You probably also have an entry in Etsy Group and Etsy G Shadow. You have the home directory itself. You have all the SideCore databases. The goal with this is, yeah, self-contained home directories. Everything that is on the stick comprehensively describes the home directory. By the way, I'm putting this stick here because it's not supposed to be just about the stick, right? The fact that we can have home directors on the stick is kind of a nice side effect of what I'm doing. But my main focus is actually not that. Most people probably want to have the home directory on the laptop. I know this and that's what I want myself. I just want to make the point that it should be that migratable that you can have it on a stick and it kind of makes sense. So yeah, self-contained home directories, right? The metadata about the user should not be distributed information about the user itself with all the resource management and stuff. It should be part of the home directory itself. This then means that the mere existence of the home directories file where everything is stored should synthesize the user account in full, right? It should make sure that if you call getPWNAM or something like this, like the classic UNIX APIs to query user, the mere existence of the user file store should synthesize everything else, right? In a way, you could say I want that, yeah, you know, UNIX, everything's a file, that, yeah, users should be a file too, right? Like where you just have one concept in the file system and that everything else comes from there during runtime and is not propagated persistently anywhere else. One of the goals that I also have is UID assignments should be a local artifact, right? I want that if I stick this USB stick into this laptop that I might get a UID and stick it to another one and that UID is already used by another account there, they get a different one and it shouldn't matter, right? This is a hard problem. We have to cut some corners to implement this, but, yeah, I want that in a way, in fact, it's when this home directory is bound to this specific laptop, it gets a user ID assigned and that's how it is, but if it's bound to a different laptop as well, it might get a different one there, so that the propagation of the actual UID numeric value is not necessary and all this infrastructure having centralized databases like LDAP and stuff to stabilize this are not necessary. I also wanted a unification of the user password encryption key. This is what I already mentioned earlier. So far, we had the encrypted password in EtsyShadow like this Unix password string, $1 $6 something and we have usually the hardest encryption like the blocks password. I don't want this to be two different things. I want this just to be the same thing. If you're capable of decrypting a home directory, that's good enough as authentication that you're also allowed to and also the reverse should be true, right? If you're allowed to log in, only then there should be any chance for you to access the home directory. So, yeah, I want these two concepts to just be merged and be the same thing. Also, and this is really important, we should have like in 2019 extensible user records, right, so that people can put in these user records whatever they want, right, and we propagate that through our APIs to have a wants to know this and, yeah, so that we are not stuck to struck past WD, right, this five field structure defined in 1985 or something but people can stick in there whatever they want, like if they have some weird requirement for their own company they can put something there and if other people have different requirements they can put something else there, but we agree on a common basic vocabulary but are highly extensible. Also, one of my really important goal actually is to lock locks on system suspend. So, nowadays I'm pretty sure that first of all, most of you probably use heartless encryption on your laptop and second of all, I think most of you probably don't even turn off the computers anymore at all, right, like usually you just close the screen and that suspends the system and then when you come back you just authenticate again. But this systematically, I mean it kind of defeats the encryption, like the encryption that you have there because basically the way it's currently implemented you use heartless like full disk encryption so while the system is up, suspended or running we are up in that context the decryption key is in memory, right, so if I go through customs to a country that I don't trust and I have the laptop with me and it's suspended and they pick up the laptop in that memory you'll find the decryption key from a heartless and that's something I think we should not do, right, we should and this is something that people might not find important but I think it's actually one of the most important things in this entire approach at all is yeah, when you suspend the system the decryption keys need to be removed from memory, right so that I know for sure that if somebody steals my laptop in suspended state because that is the most common state that they will probably steal my laptop in they should not be capable of getting any access to my hard disks, right again, this is something you really really should care about because it basically so far defeated all kind of encryption that you had because yeah as long as you did system suspend and everybody of you does that if somebody steals your laptop they can get everything they want so doing this is actually much harder than it sounds at first like because we, the reason why we're not doing this on general systems right now is because yeah if you use full disk encryption and the operating system itself is encrypted right so if you come back like if you actually flush out the cryptographic keys when you go down for a suspend and then you need to require them from the suspend who's going to ask the question if it can't even be loaded into memory because it itself resides on that encrypted petition that you want the password for, right so there's a bit of a chicken act problem and nobody solves this so far with this I want to solve this right so that when I suspend my machine the operating system itself is independent of the individual home directory so that we can suspend the home directories independently of the system itself and hence solve the problem also I kind of indicated this already I think we need to move to more modern ways of authenticating yourself to the system passwords great but also maybe we should do something better so yeah one thing I want to be able to deliver from day one of this system home this thing is UB key support I mean UB key I put in the sense of how you would use the word Google for search engine it's not just about UB keys it's about anything that is like an authentication token that implements PKCS 11 and I think we should do it properly meaning that we actually use the cryptographic properties that a UB key provides and hence yeah if you don't have the UB key that there's no way in the world the cryptographic key for unlocking your account and for accessing the data on disk can even be retrieved so that's the goal goals that I have there's some complications with all of this SSH logins I mentioned that I wanted that user authentication and decryption of the hard disk is the same thing this is inherently incompatible with how SSH traditionally works because as mentioned if you authenticate via SSH it goes via the authorized keys file in the home directory so if you want to authenticate something that is inside of the home directory so that you can access the home directory where does the decryption key come from to access the home directory you follow what I mean there's a chicken neck problem you're reading out the key that allows you access from the encrypted thing which you only can after you authenticate it so my answer to that is we don't allow SSH logins as long as you have not locked in first locally because I mean allowing SSH logins the way that traditionally done means that inherently the home directory of the user needs to be accessible before the user locks in and I think that's something I really don't want to have I really want that when I'm locked out here that not me but not also anything else in the system can even access my home directory that includes open SSH to read the keys from that so my answer to this is SSH logins into systems that use this can only be done after I logged in locally which decrypts the hard disk makes it accessible and then SSH can access and everything's fine also by the way actually the authorized keys files something I I think I already implemented even should be part of the user record so that you can actually yeah it's just there and yeah this already actually works this space assignments are a bit of a problem right we probably should come back to this one later a little bit when I talked about how the storage of what I'm doing is actually done another problem is UID assignments I kind of already indicated that so the problem is if we want the UID to be specifically local to the system right it might happen because the range of user ID is very small like it's just 32 bit that there will be collisions right like that if I have my home directory on this laptop and then take out the USB stick put in another laptop that somebody else might have already used the UID that I used here yeah this is very likely because the space is so small ideally the kernel would help us with this right because we had something like shift of S so that it doesn't matter what's actually on disk that as the moment where I log in I get assigned the UID and then I mount virtually all the files to the right user ID we can't do this so we go for the next best thing which is churning recursively if we have to and try to avoid really hard having to do this if we can thankfully churning recursively surprisingly fast actually if we actually have to do this and I'm kind of okay with the behavior of this because I mean we tried very hard to make the UID assignment stable so for example we hash it from the username but that's never going to be enough because the name space is so small but this basically means that probably in in real life if it's just Leonard and I have like three machines and I take this one out and move between them I will probably never need the churning but it's there to make this safe and ideally and sooner or later we don't have to do the churning anymore yeah looks locking I already mentioned that that this is kind of complicated but there's also a couple of other complications if we do the looks locking on suspend right like where we remove the cryptographic keys from memory as we go into suspend mode we need something that queries for the password again when the machine resumes because until that happens the home directories are locked completely locked and cannot be accessed because there's no cryptographic key known for them so we actually need cooperation for this from the UI like everything else that I'm doing here I can do without any UI involvement but in this case we need some some cooperation from the UI specifically meaning that when the system comes back from from looks your display manager like gdm whatever use will have to reassent the user because I mean mostly effectively they already do this but they do it the wrong way right now because mostly the way that they do it is that the screen lock that is turned on on suspend actually runs under the user identity of the user itself this doesn't work if we suspended the home directory of the user because we can't run code until under the user's own identity until the home directories resumed again so what we need here is that gdm for example is patched that when it comes when the system comes back from resume it asks the password again so that we can unlock the home directory and we can switch back to the user login session so I know this is a lot of material so far let's now actually have a look in the actual stuff I did on the actual code concepts yeah there are two new concepts like one of them is I want to go for jason user records like everybody knows jason jason is like what the internet people all do I think we should just start using that for our user records yeah the reason why jason is because it's just the most basic thing it's supposed to be machine readable it's not supposed to be so much something you write it's something the computers write for you and things like that and it's also what probably most of the internet facing user database is probably used anyway when they exchange information about users across the network so that's the first thing jason user records it's supposed to be a super set of the nss, nss is the name switch of glipsy it's like a generic term glipsy uses for struct past wd instruct group which for the ones who don't know unix so much that's how user records are done by glipsy since then 1985 these jason user records are supposed to be curable via vialing for those who don't know is a very simple IPC system it's just uses jason and it's supposed to be the most trivial IPC in the world so that as long as you have your own jason parser you don't actually need any kind of other code base I have a slide later why vialing is the right answer here and not debuts there are good reasons for this yeah the idea is also that from these jason user records that are curable via vialing interface we can convert forth and back between this and the classic ones in one direction of course it's lossy because jason stuff can have any kind of metadata while struct past wd instruct group cannot how does this specifically look like this is an example now if I had a laser pointer I could show you I think some of them this is pretty much self-explanatory like username you guessed it is username this position is just yeah ignore that nice level for example configures that when this user called groby logs in that all his processes get nice level 5 right it's pretty self-explanatory member of means this user is supposed to be member of the group wheel I think yeah what's interesting here is the binding thing binding is supposed to bind a specific user record onto a specific system the reason why this is a sub-object and not part of the main thing because depending on specific systems resource management is probably going to be different right like if I have a user record for you Leonard on my desktop my super beefy desktop and I want to put a size limit on it it should be specific to that desktop because it has so much more memory than my laptop might have right so the binding concept here basically you see that hack string that's actually the Etsy machine idea basically just says yeah the following properties apply only if this is bound to a specific system and then yeah GID is the GID UID is the UID what you see there is like meta information about how the actual storage is done we'll talk about this a little bit later this continues privileged is a special section that contains a privilege information basically what Etsy shadow is the reason why it's a sub-object is so that we can strip it if somebody is not supposed right so the idea basically is that all the information that is an Etsy shadow traditionally plus all the new stuff that people want to come up with should be in a specific sub-object so that whenever somebody who shouldn't see this information wants to see the record we can automatically remove it anyway I don't want to go too much detail about the structure of these records there's documentation plenty about this what's also interesting is you can sign these we'll talk about this later why that's interesting so that was concept A extensible, JSON, user records plus an API how to query them kind of replacing getPWN but also compatible concept B is I want that home directories are encrypted lux loopback files in slash home right so that you know if I have a user called foobar in slash home traditionally there was slash home slash foobar I want that there now is slash home slash foobar dot home and it's a file and it's actually a lux loopback image and then when the user logs in what do we do we set it up via lux stuff as a loopback file and then we finally mount it after validating that everything's okay these extensible user records are supposed to be stored inside of that image inside a file dot identity that's nothing magic about that this stuff is supposed to be managed by a tiny diamond and it's actually not, it's really small because it doesn't do much that is called system.homed.service what does that thing do it's okay I have not much time left there's so much more awesome stuff in this but let's let me finish this quickly so system.homed what it actually does is it just the thing that sets up these home directories as you log in right and it also provides NSS interfaces so that the old APIs all work right so that you can do get to end on the shell for example to get the user database and find then automatically all these user records and everything works this concept B like this encrypted lux stuff can be used like it relies on concept A but concept A you can actually use without it right so if you just care about the extensible user records that's totally fine and you should by the way because like even if you have the LDAP classic user databases you might want to be able to hook up hook into system.d resource management because all this new stuff is hooked into system.d's user management like for example there's PAM system.d that has been around for a while but what it does actually takes the JSON record pulls all the resource control that makes sense like from from the nice level as you have already seen the classic resource limit but also environment variables and that kind of stuff sets it for all the pros that log in there is also support in system.d login.service which kind of does the same thing when you log in but it applies it to the C group stuff right like so that it applies to the user as a whole right so if you are into LDAP and provide these extensive user records just by doing that you get this integration to get all the fancy resource management you ever dreamt of yeah so I think this I kind of already explained this but yeah I care about encrypted home directories and loopback files I care about encrypted home directories on block devices like this USB stick for example so that we have something truly migratable there while this is what I tell people I'm going for right like encrypted look stuff actually the system.d home.d component does not just support that as a back end it actually has four more back ends like classic plain directories for compatibility but our SAP volumes FS crypts and looks but again looks that back end is the one I want to push those tools towards because it's the only thing that's actually fully secure because not just the payload of the user but also the metadata is encrypted and it's fully featured and all these kind of things industry standard and stuff like that I mean this is after all an exercise and not coming up too much new stuff but just taking what's already there and that is looks for example but anyway my time over I'm fully aware that I totally did not finish all the beautiful slides I have there these slides have been online for a while but I probably should take some questions at least yeah somebody has a question there can you like there's a mic thanks so in the user the JSON structure there was a list of groups for the user so that needs to be somehow verified by the system right so how do you approach that because user can change like whatever groups he is and then it will ultimately gain access on whatever systems they look in right I mean the explanation isn't this thing in the signature so basically the user records are supposed to be changeable by only privileged like the administrator or whoever manages user record and each system will only accept the user records that are signed by the right people where the key where the signature can be verified and the key is known for this right and this is actually it's not an option like in at least if you manage stuff with system D Home D it will insist that everything is signed like we live in a world where cryptography is everything right so yeah this stuff will refuse allowing you to log in on a random use B-Stick it will only allow you to log in with random use B-Sticks that have a user record on it that is signed by some key that is recognized by your specific laptop and you can recognize as many as you want so you can change that file as much as you want but if you do you just lock yourself out because you can't sign it because you don't know the private key being used yeah so the question was whether you need privileges to change the SSH key of your own user account yes you do it's the same way as it always was for changing your password that also requires privileges this is hidden from you usually by suing suit and it's the same way we can hide this through policy kit but yes I mean there's no way that your code pass that run until your user identity can make these changes and I'm pretty sure that's how it should be if there is desire to allow unprovided users to change some artifacts of the user records it always needs to go through privileged component that's policy kit whatever else to allow this so if I got you correctly you said before that you need to login first in your account before being able to do an SSH login to that let's say I'm a university student and I have an account on the university lab and I'm at home and I want to access my account on the university lab computer but of course the system was rebooted overnight so I cannot travel 200 kilometers to how would we handle that use case would it be possible for instance to store the SSH key as a looks key and to change open SSH to unlock my home I mean SSH doesn't deal on passwords it gives you a challenge and you're supposed to respond to that and if that kind of stuff means that the only way you can do things if the other side you're syndicating against is an active program that's not how looks works looks you authenticate against a disk image so this is inherently incompatible you cannot use at least I don't see how you could use SSH authentication to decrypt a home directory that is semantically incompatible so my answer to this is if you really want that the system can come up on its own and decrypt your data don't use the stuff this is about security this is not about giving up any kind of access to your data this is about supposed to protect the system to protect your data from the system as much as possible so that when you're not locked in it's really cut off mathematically cut off and regarding to SSH what about having SSHFS reverse so that your local home folder you already decrypted and opened is used over there and then the credentials inside of that is somehow unlocking over there the homes you know what I mean this of course always works like I mean yeah if you so you know for the UB key support I'm not sure if you know UB key stuff there's this general accepted API for accessing security tokens it's called PKCS11 and there is a project inside of Red Hat and it's actually I think including Fedora and everything which allows you to propagate PKCS11 devices across the network through SSH for example and that kind of stuff you can make all the security encryption keys and all that stuff that is available locally also available on a remote system to do that kind of propagation I was interested in this because I wanted to make it possible like I have a UB key in this device and I would ideally would like to just use that to authenticate through SSH onto another system that runs system be home D and so that yeah the crypto key is sanely encrypted through that right through this PKCS11 forwarding I'm not sure how realistic that is in the short term but I'm kind of yeah well let's see how that works but again I mean the other way right that we were just talking about like logging over SSH into my laptop I'm not so sure that's that much of a common case because my laptop is a client it's not a server right like you usually lock from it into other systems you usually don't lock so much into your laptop from the outside it's like philosophically yeah sorry having oh on the other system I mean sure yeah I mean there's the solutions like I mean one thing that is actually kind of nice is like you could even share these locks files via NBD and then they show up on other systems and then you can log in there and it will just work because yeah a USB stick is not very different from NBD or something like that but that's out of focus for everything I mean my main focus really I want my own laptop finally secure that I can suspend about this I mean this is kind of like the this is a summary after all right I want these problems to be solved finally because we never could solve them and I want to solve for my own machine because I care about the security and these kind of things right so if you remove the lux encryption key on suspend does that mean that you have to log out so are all processes terminated? no and then follow up question if the process are not terminated will there still be some private data in the memory in running applications right? sure so yeah I mean there's data and there's data there's crypto keys and there's your private data yes if like I mean if I would if I steal your laptop and try to extract the memory the first thing I'm looking for is having the crypto keys that's the one we definitely should kick out people using crypto swap and these kind of things I don't know maybe there's something more to solve there so that as much as possible the kernel flushes out all the memory onto disk into swap or something and then it's encrypted and stuff like that but that's outside of my area of expertise and what I can solve I just want to solve like the really obvious stuff yeah but anyway when the system goes down we will suspend the lux device and that basically means that any process accessing it at the time will hang while it does that until we resume it again this sounds ugly and is ugly but also it's not much of a problem because we go down anyway into system suspend there's not going to be any process that might hang because the CPU holds it anyway so so if I want to have my home directory migratable but also as a backup let's say I back this up to a separate disk then I also need to back up the signing key of the signature file the key that was used to sign there so I can log back into the system if I have to restore it this stuff ultimately it's just the lux file system you can use the classic lux like crypt it up to look into this and do whatever you want and lux of course has no understanding of user records for a backup it really doesn't matter that you retain the original signing key or signing keys controls who can log in it does not control who can access the data if he knows the password so for backup it's totally sufficient to just take that one file and back that up by the way it's, I mean this is something people should never forget because this says that the user record and the home directory all become one file you can just take that file from one laptop to another laptop and you don't need to do anything at all anymore for the backup case I think it would even make a ton of sense that if the backing file system or slash home is something like XFS or ButterFest or something you can do a raffling copy every day of something of that one file and there you go you have perfect time machine kind of stuff I mean this opens up really nice possibilities as soon as we unify everything into one file because yeah in Unix most things are focused on one file anyway I think my time is mostly over but maybe one more question there okay how do you plan to deal with different distributions and versions of distributions because we have different versions of software and even if you use common home directory you will it would be not working configuration so I mean system.ly is a part of system.ly that's kind of the goal right like and unless people patch around this heavily in the distribution it's kind of going to be the same thing in all the distributions all the stuff that I'm explaining here is not supposed to replace or modify the existing users that you might have right this is an add-on right so that if you have a home directory like this great it will show up in your user database and everything's great and because it's in this version it's going to be compatible but if you're talking about the software that is inside the home directory people kind of solve this because NFS shared home directories always work like this already right and it's a mess and I don't care so much it's a problem I'm not going to solve for you right I'm not going to make sure that every version of Emacs packaged by any version of any distribution can read the same configuration files that's something other people have to solve but I at least want to make it possible that the home directories are truly migratable and yeah how migratable then they are between the distributions that's not my problem to solve I just want to make sure that the lower levels they will be perfectly migratable because I mean Lux if I compile if I format the Lux volume on Fedora and then run it on Sue it just works they did not break compatibility and since this is really just Lux yeah any very last question or are we done if you