0and see what happens
Considering #1048 which is being worked on, can either of you see any mileage in adding an extra option to simply disable the mount? I can look into that.
@metalefty - I've been looking at #1684 recently. The design choices made by the systemd team are requiring the PAM auth and session code to be called from the same process, which currently isn't the case - at the moment the auth code is called from the main sesman process and the session code is called from the first fork() process.
That's relatively simple to fix for the SCP V0 code, but a bit messy. The SCP V1 code is harder. This code also has a denial-of-service problem I've just found which I'll send you privately.
I've had a look back through the git logs for SCP V1, and nothing significant has happened to it since 2008, when you made some changes.
My proposal at the moment is to disable the V1 code we're not using and fix the V0 code for #1684. After that, I think a bigger change is required to use separate forked processes to handle all authentication requests as part of an improved V1 API. This will let us implement things like password changes and proper 2FA, but will take a bit longer to implement and be more disruptive.
How does that sound to you?
OK - thanks for the clarification.
I'm happy to stick with the current way of doing things with SCP V2, but I was wondering if you had any thoughts on maybe using a more modern style protocol based on something like JSON. We don't need a lot of performance from the sesman interface. The disadvantage would be more dependencies, but we'd gain (potentially) an interface that's easier to debug and tools could be written in a scripting language which might make the whole project a bit more accessible.
I don't personally have any particular technologies to suggest or recommend in this area. At the moment I'm just interested in what your thoughts are.
Meanwhile I'll get on with a fix for V0 and disabling V1.