IRC chat logs for #ltsp on irc.libera.chat (webchat)

Request log from specific day:

Channel log from 11 June 2019 (all times are UTC)

00:26	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
01:22	lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br)
02:02	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
02:19	ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 244 seconds)
04:07	quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4)
04:10	quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
04:11	lucascastro has left IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br, Remote host closed the connection)
04:12	lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br)
04:25	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:03	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 244 seconds)
05:19	kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60)
05:20	lucas_ has joined IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br)
05:20	lucascastro has left IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br, Read error: Connection reset by peer)
05:31	gdi2k__ has joined IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
05:33	gdi2k has joined IRC (gdi2k!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
05:33	gdi2k_ has left IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 248 seconds)
05:40	lucas_ has left IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br, Ping timeout: 245 seconds)
05:45	gdi2k__ has left IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Quit: Leaving)
05:59	gdi2k_ has joined IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
05:59	gdi2k has left IRC (gdi2k!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 248 seconds)
06:00	stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
06:03	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:07	woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
07:08	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:19	<alkisg> Yey yey yey! We can use pam_exec for ssh authentication! No need for libpam_sshauth or anything! And it's even preinstalled, so we can use it in live CDs too!
07:20	That means that there are no obstacles anymore; ltsp19 should be ready in September, without security concerns in the default installation
07:24	I thought that pam_exec would only be able to run a script, but it can return success/failure too, and it works fine with DMs, and it can even show stdout messages of our script (e.g. invalid password)
07:37	Hmm this might be useful for non-LTSP installations as well; `apt install ltsp-sshauth; ltsp-sshauth server 1001 60000` ==>
07:37	WARNING: do you really want to fetch all user accounts with uids=1001..60000 from the server, and add them locally, and authenticate them via ssh from now on (y/n)?
07:37	WARNING: additionally, do you want to have their /home/username mounted via SSHFS on login (y/n)?
07:43	statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
07:45	<alkisg> To make DMs and accountservice behave as usual, when a user is added on the server, the sysadmin will need to run a command (e.g. ltsp initrd) to propagate the new passwd/group to clients; but no action will be needed for changed passwords; small price to pay for avoiding ldap/kerberos/nfs4 :)
08:57	<gdi2k_> morning Alkis
08:57	Your SOCKS solution is working great :)
08:57	we would like to deploy it to our other site too if possible
09:00	<alkisg> Heya Graham, let's go private
09:06	GodFather has left IRC (GodFather!~rcc@143.59.184.72, Ping timeout: 248 seconds)
10:55	gdi2k__ has joined IRC (gdi2k__!~gdi2k@217.33.65.221)
11:07	GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
11:09	gdi2k__ has left IRC (gdi2k__!~gdi2k@217.33.65.221, Remote host closed the connection)
11:28	woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
11:36	gdi2k has joined IRC (gdi2k!~gdi2k@217.33.65.221)
11:51	Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:06	stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 258 seconds)
12:09	GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 245 seconds)
12:22	gdi2k has left IRC (gdi2k!~gdi2k@217.33.65.221, Ping timeout: 244 seconds)
12:31	gdi2k_ has left IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Remote host closed the connection)
12:46	woernie has joined IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de)
12:50	ogra_ has joined IRC (ogra_!~ogra@216.113.24.68)
12:51	ogra_ has left IRC (ogra_!~ogra@216.113.24.68)
13:38	gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
13:45	ogra has joined IRC (ogra!~ogra@ubuntu/member/ogra)
13:46	woernie has left IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de, Remote host closed the connection)
14:01	stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
14:01	gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Read error: Connection reset by peer)
14:04	gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
14:09	gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Read error: Connection reset by peer)
14:10	GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
14:22	lucas_ has joined IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br)
14:25	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds)
14:34	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
14:48	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
14:58	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
15:03	lucas_ has left IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br, Quit: Leaving)
15:15	gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
15:37	gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Quit: Leaving)
15:44	gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
15:44	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:49	<alkisg> vagrantc: AWEsome news; pam_exec is all we need, we don't have authentication problem anymore: http://irclogs.ltsp.org/
15:50	Since we'll already have the user geometry and the user is there, we can get the password via pam_exec, test it against ssh, and return success or failure from pam_exec, replacing pam_unix completely
15:51	passwd and group will be merged from chroot+server on boot so that accountsservice will pick them up, while gshadow and shadow won't need any hashes, not even like LDM_HASH_PASSWORD, as pam_exec can auth the screensaver too
15:52	I tried hooking pam_exec to auth, and it works beautifully; I'll even arrange so that ltsp-pamauth can work without ltsp too (in lan environments where they want ssh-based auth and optionally sshfs)
15:55	<quinox> neat
15:55	<vagrantc> alkisg: that is good news!
15:56	<alkisg> No blockers for ltsp19 anymore, just a matter of scheduled work
15:56	GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 258 seconds)
15:56	<vagrantc> i know scotty looked into pam_exec originally ... wonder why
15:57	<alkisg> It even shows stdout to gdm (I haven't tried lightdm yet, trying with buster-gnome), so I can notify "invalid password" or "unknown server"
15:57	I don't think I'll be able to do expiry though; those that want expiry can set up ldap-client in the chroot
15:59	<vagrantc> that is exactly what scotty needed.
16:00	this is really exciting
16:00	pam_exec is included just about everywhere
16:03	alkisg: did i read the irc logs right in that it needs the username/id locally?
16:05	alkisg_web has joined IRC (alkisg_web!822b520c@130.43.82.12.dsl.dyn.forthnet.gr)
16:06	<alkisg_web> Meh work server got offline due to rain/power issues :/
16:06	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds)
16:07	<alkisg_web> vagrantc, I did a quick try of adding the user right in the middle of pam_exec; it didn't work out
16:07	And, having the user geometry beforehand, allows to show them in gdm/lightdm, allows accountsservice to know them etc, much better
16:08	<vagrantc> ok, so that's a bit of a regression, and a bit of a feature :)
16:08	<alkisg_web> So I guess these 2 modes much be enough, i.e. passwd on the server + geometry on the client + pam_exec, or ldap in the client
16:08	Right, ldap on server only won't work anymore, the chroot will need to be configured properly
16:09	I do design a regex for user selection per client though, e.g. pc01 will only list a01-/b01-/c01-* users
16:09	<vagrantc> so you need to rebuild the initrd every time you add a user?
16:09	<alkisg_web> Configurable from lts.conf
16:09	<vagrantc> or we have some other mechanism for transmitting user information?
16:10	<alkisg_web> We could also have a small service; but for gsoc, I want to avoid web services if possible
16:10	<vagrantc> this sounds like a good starting point
16:10	<alkisg_web> I want web services to be another big design in the future, with epoptes-like control of the clients, and of course configuration sending
16:10	<vagrantc> a little nervous about how the user data is transmitted ...
16:11	<alkisg_web> In the future, https. Now, the initrd; but only passwd + group, not shadow
16:11	<vagrantc> alkisg_web: we're talking /etc/passwd and /etc/group, basically?
16:11	<alkisg_web> Right
16:12	I'll send them verbatim to the client, and the client can merge them on boot or whenever they see fit; I can also update them on ssh logins, or even via epoptes, but I'd like to avoid https for now
16:12	<vagrantc> could set up a dedicated ssh user that just has access to two commands: cat /etc/passwd ; cat /etc/shadow
16:12	<alkisg_web> But when are you going to run that command...
16:12	<vagrantc> at boot
16:12	gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Quit: Leaving)
16:12	<vagrantc> rather than at initramfs generation
16:13	or rather, ltsp-cpio ...
16:13	or maybe even at *DM startup
16:13	GodFather has joined IRC (GodFather!~rcc@2600:1007:b11f:4255:cc9d:c806:4f22:35cb)
16:13	<alkisg_web> We'd need to tell users to restart the DM then
16:14	If we want them to refresh passwd
16:14	<vagrantc> well, right now you need to tell users to reboot
16:14	<alkisg_web> Or login
16:14	We can update passwd on login
16:14	<vagrantc> or rather, with putting it in the initrd
16:14	<alkisg_web> Eh we can automate that part on the server more easily
16:14	ltsp-initrd needs less than 1 sec
16:15	<vagrantc> and a reboot of client
16:15	<alkisg_web> If we want, we can put an inotify hook in /etc/passwd and update initrd 3 secs after last change
16:15	<vagrantc> sure
16:15	<alkisg_web> But, if someone is using epoptes, he can do it without all these
16:15	<vagrantc> ah, true
16:16	<alkisg_web> He can just run "ltsp-pamssh -temp-web-server" on the server, which would load a python simplehttpserver with just passwd and group,
16:16	and "ltsp-pamssh update-passwd" via epoptes on the client
16:16	And that command can restart the DM too
16:17	statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
16:18	<alkisg_web> could set up a dedicated ssh user that just has access to two commands: cat /etc/passwd ; cat /etc/shadow ==> would you ship such a package?
16:19	We can also only allow this via key authentication, and put the key to the initramfs
16:19	<vagrantc> alkisg_web: i meant /etc/passwd and /etc/group
16:19	exactly
16:20	<alkisg_web> OK imagine this without ltsp temporarily
16:20	<vagrantc> or getent passwd ; getent group ...
16:21	<alkisg_web> The sysadmin installs that service, copies the pamssh user key to the clients, and they can fetch the newer info whenever they want
16:21	Does it sound sane, security-wise?
16:21	If so, sure, we can focus there, as it won't require any other services as dependencies, just ssh on the server
16:23	Btw, with pam_exec and the user already existing, I can have the ssh socket owned by the user; e.g. "remoteapps without daemon" or whatever else we want
16:23	<vagrantc> a little bit of a user discoverability risk ... some remote execution risk (though you can narrow that significantly with keys)
16:23	alkisg_web: the simplicity of having the pre-existing users is pretty compelling ... just curious about updating the passwd/group databases
16:23	<alkisg_web> server: pamssh install => creates pamssh user without login shell, and they key; then the sysadmin copies that key to clients/root/.ssh/
16:24	About merging, I'm thinking of this: `merge min_uid=1001 max_uid=60000 regex='a.\|b.\|etc'`
16:24	<vagrantc> the security of the ssh user effectively can gain root on any client ... which is basically also true of the tftp server
16:25	<alkisg_web> That would keep administrator=uid 1000 a local user, in case it's needed for logging in completely locally
16:26	<vagrantc> hard-coding specialized uid/gid information could have incompatibilities for individual installations
16:26	<alkisg_web> Sure the tftp is a major security risk but not a lot we can do about that at this point
16:26	That's a user command
16:26	I.e. the sysadmin provided those values in the cmdline
16:26	(or in lts.conf etc)
16:26	<vagrantc> yeah, just comparing the relative risks of tftp vs. the dedicated ssh user
16:27	alkisg_web: ok
16:27	<alkisg_web> The other idea is to just read login.defs and merge all non system users; but I like the min_uid/max_uid/regex idea better, it's more versatile
16:27	<vagrantc> if it's configurable, it's all good :)
16:27	<alkisg_web> Or I could read the min/max from login.defs, and only allow a regex
16:28	regex can do "a* but not administrator"
16:28	stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 258 seconds)
16:28	<alkisg_web> I hope people won't need groups there :P
16:28	<vagrantc> merging system users is a bit tricky, since there may be group drift depending on the order of package installation
16:28	and system groups
16:28	<alkisg_web> (e.g. allow only users from group "students" to login there"
16:28	I won't merge system users at all
16:28	I'll keep the target system users
16:29	<vagrantc> i think technically uid range for non-system users is 500-60k+
16:29	<alkisg_web> Or I could read the min/max from login.defs, and only allow a regex ==> hmm yeah I think that's best, and possibly allow for group regexes too
16:30	<vagrantc> how do you merge, say, a different gid for "audio" on the client vs. the server?
16:30	by gid, or by name?
16:30	<alkisg_web> By name
16:30	I don't touch system groups
16:31	So if alkisg is a member of audio, IF audio exists on the target, then alkisg will also be a member of that there, whatever the gid
16:31	uid nowadays is 1000+, even fedora went for that (from 500 previously)
16:31	And it's standarized in login.defs now
16:32	Yes pam_exec exists everywhere btw, all major distro installations and live cds; we're only missing the squashfs module and sshfs in some cases
16:32	...I'll try to include them at ltsp-update-image time, if it's possible
16:33	<vagrantc> yeah, i know uid's are typically 1000+
16:33	including sshfs would only be possible with compatible architectures, i'm guessing?
16:34	(although with qemu-user-static or similar, many architectures can be "compatible")
16:34	<alkisg_web> chroot apt install sshfs, if it's doable over overlay in the ltsp-update-image phase
16:34	Although if people want to use live cds as test images, I guess they won't mind to use guest accounts too, with local /home
16:35	As with normal chroots/VMs, they can just install ssh
16:35	*sshfs
16:35	<vagrantc> right
16:35	<alkisg_web> (guest accounts, or nfs3 homes; live cds can support those; or, live cds can run apt install sshfs on boot)
16:35	<vagrantc> yup
16:36	<alkisg_web> the squashfs module isn't important as all live cds have it already; and it can be normally installed in chroots/vms; btw debian-live also booted fine
16:36	(debian-live.iso with the ltsp boot code)
16:37	<vagrantc> nice ... that even brings in calamares, so you could use LTSP to install systems :)
16:37	at least in theory ...
16:39	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:39	<vagrantc> alkisg_web: so, for a simple implementation, you just copy passwd/group data into the initramfs. more sophisticated implementations are a bonus.
16:39	<alkisg_web> I think i'll start with ltsp-pamssh as a separate package for lans
16:40	I think people will prefer to use that, instead of copying around passwd like they do now in some cases
16:40	I hope in 2 weeks it'll be ready
16:40	<vagrantc> this is a dedicated ssh user to copy the passwd/group data?
16:40	ltsp-pamssh?
16:40	<alkisg_web> That's the "pam service", but also the "merge passwd script"
16:41	I'm thinking to put everything in one file, so that sysadmins will be able to use ssh for authentication, and optionally sshfs for homes, in LANs, with a single file, without ltsp
16:41	<vagrantc> ah.
16:41	<alkisg_web> As I hope it'll work in all distors/DMs
16:41	And it'll be so much easier to setup than ldap/nfs4/kerberos etc
16:42	<vagrantc> then ltsp-pamssh is a bit misleading for a name
16:42	<alkisg_web> Eh it'll still be generated from the ltsp code; i just want to give them an easy way to install it
16:42	But sure, name suggestions are always welcome
16:42	I.e. I'm thinking that src: ltsp will generate 2 packages, ltsp and ltsp-pamssh
16:43	So later on they can apt install ltsp-pamssh, without ltsp
16:45	<vagrantc> ltsp-pamssh sets up the pam_exec hooks that handle ssh authentication and sshfs homes (optionally) ... and the passwd/group sync?
16:45	<alkisg_web> Right
16:45	And if we ever implement that special user, it'll do that too, server-side
16:46	(or a simplehttpserver, or anything else to ease the transfer)
16:46	<vagrantc> so outside of ltsp, where would the passwd/group sync happen?
16:46	<alkisg_web> The easiest would be epoptes again
16:46	<vagrantc> got it
16:46	<alkisg_web> Otherwise, scp + run ltsp-pamssh merge
16:47	or, on login
16:47	...maybe "on login" is the easiest one so far
16:47	<vagrantc> well, obviously on login has a bootstrapping problem
16:47	<alkisg_web> The initial one will happen with the installation
16:47	ltsp-pamssh setup => ask for a user on the server to authenticate, copy passwd, etc
16:48	like joining an AD domain, I think that asks for an AD administrator or something
16:48	<vagrantc> right
16:48	and syncing would also have to happen as an administrator
16:49	as arbitrary users could do evil things
16:49	<alkisg_web> Eh it needs root on the client, so it's safe
16:49	Btw pam_exec runs the script as root (and user gid), so we have enough rights to update passwd
16:49	<vagrantc> but sync on login?
16:49	right
16:50	just a question of how you get the updated data
16:50	<alkisg_web> Users don't manually run it there; it's pam_exec; users don't really have control over it
16:50	If the user authenticates against the server, he can login, and he can get the group/passwd over ssh
16:50	There's no "rights abuse"
16:50	<vagrantc> "get the group/passwd over ssh" is where the user on the server has control
16:51	<alkisg_web> ...all normal users can cat passwd
16:51	We don't do anything to protect from that
16:51	<vagrantc> yes, but i wouldn't trust the output from arbitrary users
16:51	<alkisg_web> I don't get it
16:51	pam_exec calls our script, which ssh's to the server using the user name/password, and our script gets the data
16:52	<vagrantc> cat /etc/passwd ... vagrant:x:0:0: ...
16:52	<alkisg_web> Do you mean that the user might be able to put things in PATH and make `cat` misbehave?
16:52	<vagrantc> exactly
16:52	<alkisg_web> If we run /bin/cat, we don't rely on PATH
16:53	<vagrantc> but you rely on the existance of /bin/cat
16:53	<alkisg_web> And how can the user block that?
16:53	<vagrantc> you're running as the user's login shell ... all sorts of trickery can happen
16:53	<alkisg_web> We're not running a shell at all
16:54	ssh can run a command, not a shell
16:54	<vagrantc> oh really ? :P
16:54	i bet you if the user's shell is /bin/false you won't be able to run arbitrary commands.
16:54	<alkisg_web> The user can't set his shell to /bin/false
16:55	<vagrantc> i'm pretty sure a shell is still run
16:55	<alkisg_web> Let's formalize this. If you have an example where the user can actually harm us, no matter how careful we are, then we shouldn't sync on login via the user
16:56	If this is just hypothesis, we can research if it's possible or not
16:56	(btw note that that's what ltsp does currently :P)
16:56	<vagrantc> at this point it's a hypothesis informed by overwhelming best practices: you don't trust unsanitized input
16:57	<alkisg_web> I don't expect the user to be able to alter the input
16:57	Without the sysadmin allowing it first
16:57	<vagrantc> i don't assume the limitations of our imagination are the best security protocol
16:58	<alkisg_web> If there's a known security issue with ssh, we can just report it
16:58	<vagrantc> and therefore defer to knowledge about best practices
16:58	<alkisg_web> But we can't rely on hypotheses that ssh might have a bug there
16:58	<vagrantc> it's not a bug in ssh, it's a bug in the proposed method of passwd/group retrieval
16:59	(which maybe we already have)
16:59	<alkisg_web> If I `ssh user@server /bin/cat /etc/passwd` and the user is able to alter the output of that command, I'd consider it a grave security flow of ssh
17:00	<vagrantc> i don't see why; the computer is doing what you asked it to do
17:00	you're getting the output of the commands run on that server, however the user has configured their environment
17:01	trusting that output blindly to configure the local system is the security vulnerability
17:01	<alkisg_web> I'm saying that the user environment should be able to affect /bin/cat /etc/passwd
17:01	If it is, it sounds like a security flaw
17:02	<vagrantc> yes, the user environment should be able affect /bin/cat /etc/passwd
17:02	but it's not a security flaw...
17:02	woernie has joined IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de)
17:02	<alkisg_web> And have /bin/cat be suid root?
17:02	<vagrantc> and while i might be able to prove that's true, i can't prove that it's not true
17:02	<alkisg_web> Then all users can become root, by just running a command :)
17:03	<vagrantc> the user could run fakechroot to make /bin/cat be whatever they want
17:03	for example
17:03	<alkisg_web> The user can configure ssh to run fakeroot?
17:03	Then why can't he configure login too?
17:04	So that people logging in as admin, will login to his fakeroot?
17:04	<vagrantc> you're looking at this from the wrong angle
17:04	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
17:04	<alkisg_web> There are fences of security that need to be respected, for security to work
17:04	<vagrantc> it's not that it would compromise login on the server ... that actually requires root privledges
17:04	<alkisg_web> If we assume that a user can chroot to his nfs root and becore root there, all is lost
17:05	If we assume that the user can modify the sshd config... it's about the same
17:05	<vagrantc> but to trust all the data from an arbitrary user to then configure, say, login on the client ... that's where the problem exists
17:05	<alkisg_web> Btw, you do know ltsp currently does just that, right? :)
17:05	<vagrantc> yes, i know
17:06	i do like to think the next version of ltsp will fix bugs in the old system? :)
17:06	<alkisg_web> Eh, we can't fix everything :D
17:06	<vagrantc> agreed
17:06	<alkisg_web> So ok, let's pass on the "sync on login" idea
17:07	I'm not convinced it's a security flaw, but anyway
17:07	<vagrantc> we can touch on it another time
17:07	<alkisg_web> It could sync using the special user then
17:07	<vagrantc> with a dedicated user, you can configure an ssh key to specifically do exactly one command
17:08	<alkisg_web> Although of course anyone can get that ssh key and login to the server then
17:08	Which is a much greater security flaw
17:08	Even if it's just to run a specific command
17:08	<vagrantc> yes, anyone can get that ssh key and run /bin/cat /etc/passwd
17:08	to their hearts content
17:09	<alkisg_web> Yes, but if an ssh CVE is discovered, it's an issue there
17:09	<vagrantc> indeed
17:09	<alkisg_web> And there's python simplehttpserver
17:10	<vagrantc> because hand-crafting an http server will always be secure? :)
17:10	<alkisg_web> E.g. epoptes, or scp, or anything non-automated
17:10	I run the server, run the sync command via epoptes, close the server
17:10	They might hack pythonsimplehttpserver in 5 secs; it's a risk I'll have to take
17:11	<vagrantc> at any rate ... shunting everything into the biggest security hole we have, tftp the initramfs ... seems like the least problematic at this point
17:11	<alkisg_web> Dunno from all those, I think I like the "sync on login" best
17:12	If some actual exploit is ever found... we might have implemented the big web service already at that point
17:12	True; well, they could put the initramfs locally, and hope that's more secure
17:13	<vagrantc> i'll try to test that sync on login is a bad idea, and if i can prove it, it's settled?
17:13	<alkisg_web> Of course
17:13	If you're worried that much, no need to test, I can discard that anyway
17:13	<vagrantc> if i can't prove it, i'm not convinced ... but if i can
17:14	<alkisg_web> And tell users to use scp/epoptes/etc
17:14	<vagrantc> the user login could trigger a sync or something reasonbly safely
17:14	GodFather has left IRC (GodFather!~rcc@2600:1007:b11f:4255:cc9d:c806:4f22:35cb, Ping timeout: 250 seconds)
17:14	<alkisg_web> Ah
17:14	<vagrantc> you just can't trust the output from the user's account
17:14	<alkisg_web> We can tell them "login as admin to sync"
17:14	If the admin wants to hack his own system, ...
17:15	<vagrantc> possibly
17:15	<alkisg_web> I.e. instead of a special user, "the user that set it up initially"
17:16	<vagrantc> this is for manually administered machines, not ltsp clients?
17:16	<alkisg_web> Yes, I'm trying to solve the general problem first
17:16	Then specialize it to ltsp
17:16	ltsp clients can use the initramfs for now
17:17	<vagrantc> got it
17:17	the admin is defined how?
17:17	<alkisg_web> The user that runs: sudo ltsp-pamssh setup
17:17	which in turn asks: give user/pass of server, to copy passwd
17:18	And saves the user name somewhere in /etc/ltsp/
17:18	sudo ltsp-pamssh setup alkisg@server ==> so the server trusted user is "alkisg"
17:18	And the connection server is defined/saved as "server"
17:19	<vagrantc> why not sudo ltsp-pamssh setup user@server
17:19	rather than asking
17:19	<alkisg_web> ^ :)
17:19	* alkisg_web wonders if webchat propagates things slowly...
17:19	<vagrantc> alkisg_web: you're writing too fast
17:20	:)
17:20	<alkisg> ;)
17:20	Yey, server is up again
17:20	<vagrantc> but at least we landed at the same place that time
17:21	i'm a little curious about "saving" the administrative user
17:21	<alkisg> We can also check if the user is a sudoer (from the geometry), and sync if he is
17:21	Assuming that if he's a sudoer on the server... well, he can hack the server directly
17:21	<vagrantc> right
17:22	<alkisg> Hopefully, bob that WAS a sudoer in our saved geometry, won't be a malicious user in the new geometry :P
17:22	<vagrantc> so, they already have sudo locally
17:22	so whatever authentication is already handled
17:22	<alkisg> (previous sysadmin that got away, then a user with the same name came)
17:23	I'm not sure what you mean there
17:23	<vagrantc> old names should be reserved ...
17:23	<alkisg> Initially, they have normal accounts/pam, so sudo and all, locally
17:23	<vagrantc> can't stop everyone from shooting themselves in the foot all the time
17:23	<alkisg> After the setup, only a few local accounts will remain, if any
17:24	So shadow will only have their local passwords
17:24	All the other shadow entries will be cleared, as pam_exec/ssh will be used instead
17:24	<vagrantc> hmmm...
17:25	so how do you define which local users are saved?
17:25	<alkisg> With the regex
17:25	<vagrantc> ok
17:25	<alkisg> sudo ltsp-pamssh setup user@server --regex='a* b*'
17:26	A min_uid/max_uid may still be needed
17:26	<vagrantc> --preserve-local-users="$
17:26	regexp"
17:27	or something other than --regex
17:27	:)
17:27	<alkisg> And after all that, pam_exec will check if the user has a local shadow entry, then it'd chain to pam_unix
17:27	If it's a non-system user, without a shadow entry, it'd use ssh for authentication
17:28	<vagrantc> wouldn't pam_exec just exit at that point and let the chain move on down the line?
17:28	<alkisg> That; I don't know yet the correct terminology
17:28	<vagrantc> i think that's generally how pam works ... you can have modules which fail and it's ok and it moves on to the next
17:29	it's configurable ... some might require success, some might be optional, etc.
17:29	<alkisg> In my first test today, i completely replaced pam_unix with pam_exec
17:29	I guess I'll put it above
17:30	At that point, I hadn't thought about local users yet
17:30	<vagrantc> anyways, sounds reasonably good thus far
17:30	<alkisg> But it'll be nice to have, for non-ltsp clients
17:30	If non-ltsp pam* works, and we get users outside of ltsp,we'll have earlier DM testing too
17:30	That it works in all distros/DEs
17:31	Thanks for the input vagrant, as always :)
17:33	<vagrantc> alkisg: thanks for all the good ideas and implementation! :)
17:38	woernie has left IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de, Ping timeout: 248 seconds)
18:44	GodFather has joined IRC (GodFather!~rcc@2600:1007:b11a:ac68:cc9d:c806:4f22:35cb)
19:22	GodFather has left IRC (GodFather!~rcc@2600:1007:b11a:ac68:cc9d:c806:4f22:35cb, Ping timeout: 248 seconds)
19:22	lucascastro has joined IRC (lucascastro!~lucascast@177.185.131.162)
19:47	alkisg_web has left IRC (alkisg_web!822b520c@130.43.82.12.dsl.dyn.forthnet.gr, Remote host closed the connection)
20:06	lucascastro has left IRC (lucascastro!~lucascast@177.185.131.162, Quit: Leaving)
20:28	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
20:43	spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 244 seconds)
20:56	Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:43	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:05	adrianorg has left IRC (adrianorg!~adrianorg@177.18.50.202, Ping timeout: 272 seconds)
22:06	kjackal has left IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60, Ping timeout: 258 seconds)
22:31	ogra has left IRC (ogra!~ogra@ubuntu/member/ogra, Ping timeout: 258 seconds)
22:35	adrianorg has joined IRC (adrianorg!~adrianorg@177.18.50.202)
23:51	dsjii has joined IRC (dsjii!~david@2600:380:a035:2b15:68db:caff:fe86:8f41)