7 ms·

This is new to me, and I watched through the video, and in usual fashion, any use case that he and his group thinks are not common, are just hand-waved away "th

This is new to me, and I watched through the video, and in usual fashion, any use case that he and his group thinks are not common, are just hand-waved away "that's not common" "You shouldn't do it that way" "If you want to use this, don't do that". Yet, all the things he mentioned, like, remotely accessing a locked laptop via ssh, or maintaining a external user database for a cluster of machines in LDAP, are things I do on a regular basis. He also mentioned something about requiring a privileged daemon to change your ssh keys? Is there any more information about that? Given the gravity of systemd, and all it's ancillary services, how long till this is the one true way? How does this work in the case of true remotely accessible multi-user systems?

NikolaeVarius 7y ago
Dont use it then
- ta999999171 7y ago
  "Just leave the country if you don't like it."
  - akvadrako 7y ago
    It’s an optional feature. I doubt many people will use it.
  - claudiawerner 7y ago
    This idea is actually quite old; Socrates himself said this when a friend offered to break him out of prison. Socrates' argument was that if he didn't like the laws of Athens he could have gone somewhere else, but by staying in Athens he consented to its laws, so it was not his right to break out now, and he should have to face his sentence of death.
candiddevmike 7y ago
Keep in mind the main use case for this is local desktop/interactive sessions. For system/service accounts, you can still use regular passwd files, SSH auth etc. As you eluded to, the problems this is trying to solve include better integration/less rough edges with enterprise authentication (AD and the like), encrypting home directories, and making home directories and user accounts more portable. Anyone that does desktop fleet management will find a lot of stuff to be excited about here.
- jasonjayr 7y ago
  I know the video had limited times, but in regards to enterprise authentication, is there any consideration to data ownership? In this scheme can the enterprise, or any superior device/data owner have a master key to decrypt home directory of a subordinate user?
  - candiddevmike 7y ago
    I do not believe so. The homectl docs state that the encryption password == user password without any alternative: https://www.freedesktop.org/software/systemd/man/homectl.html https://www.freedesktop.org/software/systemd/man/homectl.htm...
    - jasonjayr 7y ago
      Thanks for that link. I see further down that PKCS#11 is supported: > Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV smartcard) that shall be able to unlock the user account. The security token URI should reference a security token with exactly one pair of X.509 certificate and private key. A random secret key is then generated, encrypted with the public key of the X.509 certificate, and stored as part of the user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the account and associated resources. See below for an example how to set up authentication with security token. Key hierarchy management can probably be delegated to an external system.
    - nullc 7y ago
      FWIW, if you want to do dynamic mounted encrypted home you can do so today with pam_mount pretty easily. The two passwords can even disagree, you'll just get prompted twice during the login process. In fedora, at least, it requires only three lines of configuration changes (adding the pam hooks, and setting up the mount point in the pam_mount config).
    - throw0101a 7y ago
      > encryption password == user password What if your password is in LDAP, and you change it the OpenLDAP back-end? Or if you have OpenLDAP talk to AD (via SASL) for password checks, but the rest of the GECOS & group is in LDAP? Is Kerberos covered? How is NFS handled? Automounts? Doing a ^F I find no mention in the man page of either LDAP or Kerberos.
johnny22 7y ago
i don't see distros like debian ever using that as the default way, and there's no indication that the old way will disappear either.
- catalogia 7y ago
  I hope you're right, but Debian has adopted other questionable SystemD defaults in the past, such as killing nohup'd processes when the user logs out (which is absolutely inane.)
  - api 7y ago
    What? I didn't even know about that. This stuff is such absolute trash.
    - catalogia 7y ago
      A lot of people (including me) learned about it the hard way when their tmux sessions began mysteriously disappearing. The solution is KillUserProcesses=no in /etc/systemd/logind.conf Some systemd advocates say the critics are just upset at change. I don't dislike change in general, but changing defaults out from under me? Defaults like this? That irks me. I lost a several tmux sessions before I realized what was happening. I thought I was doing something wrong because SystemD violated my expectations so severely.
      - loopz 7y ago
        Turns out some people like to force change upon others. They will always win out. These same people are oblivious to cause and effect.
        deleted 7y ago
        [deleted]
      - yori 7y ago
        Why did the sessions disappear? Can you explain more about it?
bangboombang 7y ago
It sounds like enterprisey RedHat trash. Probably for better Active Directory integration, hence only CIFS is mentioned but not NFS. And they might actually achieve this there, since SSSD is another abomination that kinda does that and mostly works, but once it doesn't and you try to debug it, you want to stab yourself in the brain with a dumb object. For any other distro, I very much hope this thing is not enabled or even installed by default. Since I don't get the complaints about ecryptfs. I've been using it since around 2012 on multiple machines, multiple dist-upgrades and password changes and it never failed me once. Oh and SSHing into the machine works as expected!
- sekh60 7y ago
  What is wrong with SSSD? Granted I have never used AD, but I have a domain set up with FreeIPA and it just works for the most part. The logs are pretty detailed when the rare issue comes up, and being kerberos based 80% of the time it's a time sync issue.
  - bangboombang 7y ago
    There have been several issues over time. My general problem with it was complexity. What finally broke the camel's back for me was that for unexplained reasons, sssd stayed in "offline mode" after system standby for 30-60 seconds. We could validate that the network connection was back up after max. 5 seconds, but there was no way to get this thing to go online again. So basically we had to tell our users that they won't be able to login after system standby for a minute or so. This was impossible to debug. You could send some signal (USR1 or 2 iirc) to sssd to force it into online mode, we even tried a crude script that would run after system resume and spam sssd with that signal for a minute to no avail. Shortly after I left that department the decision was made to move to Centrify. It's a pita in other ways apparently, but everything I know about it is just from hearsay from old colleagues aynways.
nickik 7y ago
> how long till this is the one true way It not supposed to be the 'true' way. Its supposed to be an option for specific envoirmentments.
neurobashing 7y ago
my (possibly dumb) personal "conspiracy theory": some time in the relatively recent future there is going to be The Grand Linux Userspace Fork. There's going to be "SystemD with the Linux Kernel" (the SystemD system with Gnu utilities and the Linux kernel if you're into that sort of thing) and then "classic Linux", which is just "not using SystemD". We already sorta have this now. What I'm (half-jokingly) suggesting is a big ugly fork a la Emacs/XEmacs, where the world visibly and somewhat incompatibly separates. And like that fork we'll end up with everything more-or-less reconciling eventually, but it's going a weird ride until then.
- anonymou2 7y ago
  there is devuan already
- ColanR 7y ago
  I agree. When that happens, I hope Wayland joins systemD, and I hope Linux somehow merges with plan 9. That, to me, would be ideal. Let Ubuntu play corporate, and leave the hackers in peace. BTW, among other problems that the plan 9 paradigm alreay solved, I'm pretty sure they solved the security issues that Wayland was intended to solve, and from what I understand, I'm pretty sure they did a better job, too.
- tobias12345 7y ago
  I do not see that happen anytime soon: There are just no developers that could keep the stack alive over in the non-systemd camp:-( Sad but true.

NikolaeVarius 7y ago

Dont use it then

ta999999171 7y ago
"Just leave the country if you don't like it."
- akvadrako 7y ago
  It’s an optional feature. I doubt many people will use it.
- claudiawerner 7y ago
  This idea is actually quite old; Socrates himself said this when a friend offered to break him out of prison. Socrates' argument was that if he didn't like the laws of Athens he could have gone somewhere else, but by staying in Athens he consented to its laws, so it was not his right to break out now, and he should have to face his sentence of death.

candiddevmike 7y ago

Keep in mind the main use case for this is local desktop/interactive sessions. For system/service accounts, you can still use regular passwd files, SSH auth etc. As you eluded to, the problems this is trying to solve include better integration/less rough edges with enterprise authentication (AD and the like), encrypting home directories, and making home directories and user accounts more portable. Anyone that does desktop fleet management will find a lot of stuff to be excited about here.

jasonjayr 7y ago
I know the video had limited times, but in regards to enterprise authentication, is there any consideration to data ownership? In this scheme can the enterprise, or any superior device/data owner have a master key to decrypt home directory of a subordinate user?
- candiddevmike 7y ago
  I do not believe so. The homectl docs state that the encryption password == user password without any alternative: https://www.freedesktop.org/software/systemd/man/homectl.html https://www.freedesktop.org/software/systemd/man/homectl.htm...
  - jasonjayr 7y ago
    Thanks for that link. I see further down that PKCS#11 is supported: > Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV smartcard) that shall be able to unlock the user account. The security token URI should reference a security token with exactly one pair of X.509 certificate and private key. A random secret key is then generated, encrypted with the public key of the X.509 certificate, and stored as part of the user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the account and associated resources. See below for an example how to set up authentication with security token. Key hierarchy management can probably be delegated to an external system.
  - nullc 7y ago
    FWIW, if you want to do dynamic mounted encrypted home you can do so today with pam_mount pretty easily. The two passwords can even disagree, you'll just get prompted twice during the login process. In fedora, at least, it requires only three lines of configuration changes (adding the pam hooks, and setting up the mount point in the pam_mount config).
  - throw0101a 7y ago
    > encryption password == user password What if your password is in LDAP, and you change it the OpenLDAP back-end? Or if you have OpenLDAP talk to AD (via SASL) for password checks, but the rest of the GECOS & group is in LDAP? Is Kerberos covered? How is NFS handled? Automounts? Doing a ^F I find no mention in the man page of either LDAP or Kerberos.

johnny22 7y ago

i don't see distros like debian ever using that as the default way, and there's no indication that the old way will disappear either.

catalogia 7y ago
I hope you're right, but Debian has adopted other questionable SystemD defaults in the past, such as killing nohup'd processes when the user logs out (which is absolutely inane.)
- api 7y ago
  What? I didn't even know about that. This stuff is such absolute trash.
  - catalogia 7y ago
    A lot of people (including me) learned about it the hard way when their tmux sessions began mysteriously disappearing. The solution is KillUserProcesses=no in /etc/systemd/logind.conf Some systemd advocates say the critics are just upset at change. I don't dislike change in general, but changing defaults out from under me? Defaults like this? That irks me. I lost a several tmux sessions before I realized what was happening. I thought I was doing something wrong because SystemD violated my expectations so severely.
    - loopz 7y ago
      Turns out some people like to force change upon others. They will always win out. These same people are oblivious to cause and effect.
      - deleted 7y ago
        [deleted]
    - yori 7y ago
      Why did the sessions disappear? Can you explain more about it?

bangboombang 7y ago

It sounds like enterprisey RedHat trash. Probably for better Active Directory integration, hence only CIFS is mentioned but not NFS. And they might actually achieve this there, since SSSD is another abomination that kinda does that and mostly works, but once it doesn't and you try to debug it, you want to stab yourself in the brain with a dumb object. For any other distro, I very much hope this thing is not enabled or even installed by default. Since I don't get the complaints about ecryptfs. I've been using it since around 2012 on multiple machines, multiple dist-upgrades and password changes and it never failed me once. Oh and SSHing into the machine works as expected!

sekh60 7y ago
What is wrong with SSSD? Granted I have never used AD, but I have a domain set up with FreeIPA and it just works for the most part. The logs are pretty detailed when the rare issue comes up, and being kerberos based 80% of the time it's a time sync issue.
- bangboombang 7y ago
  There have been several issues over time. My general problem with it was complexity. What finally broke the camel's back for me was that for unexplained reasons, sssd stayed in "offline mode" after system standby for 30-60 seconds. We could validate that the network connection was back up after max. 5 seconds, but there was no way to get this thing to go online again. So basically we had to tell our users that they won't be able to login after system standby for a minute or so. This was impossible to debug. You could send some signal (USR1 or 2 iirc) to sssd to force it into online mode, we even tried a crude script that would run after system resume and spam sssd with that signal for a minute to no avail. Shortly after I left that department the decision was made to move to Centrify. It's a pita in other ways apparently, but everything I know about it is just from hearsay from old colleagues aynways.

nickik 7y ago

> how long till this is the one true way It not supposed to be the 'true' way. Its supposed to be an option for specific envoirmentments.

neurobashing 7y ago

my (possibly dumb) personal "conspiracy theory": some time in the relatively recent future there is going to be The Grand Linux Userspace Fork. There's going to be "SystemD with the Linux Kernel" (the SystemD system with Gnu utilities and the Linux kernel if you're into that sort of thing) and then "classic Linux", which is just "not using SystemD". We already sorta have this now. What I'm (half-jokingly) suggesting is a big ugly fork a la Emacs/XEmacs, where the world visibly and somewhat incompatibly separates. And like that fork we'll end up with everything more-or-less reconciling eventually, but it's going a weird ride until then.

anonymou2 7y ago
there is devuan already
ColanR 7y ago
I agree. When that happens, I hope Wayland joins systemD, and I hope Linux somehow merges with plan 9. That, to me, would be ideal. Let Ubuntu play corporate, and leave the hackers in peace. BTW, among other problems that the plan 9 paradigm alreay solved, I'm pretty sure they solved the security issues that Wayland was intended to solve, and from what I understand, I'm pretty sure they did a better job, too.
tobias12345 7y ago
I do not see that happen anytime soon: There are just no developers that could keep the stack alive over in the non-systemd camp:-( Sad but true.