here's xrdp development talk room, questions here: https://gitter.im/neutrinolabs/xrdp-questions
@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.
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 totally agree with this. I personally don't hesitate to introduce modern style protocol at all. The current sesman is a maze to me.
I absolutely agree about the sesman implementation. It needs a bit of tidying up. I'll put it on the longer-term list of things to look at.
The mixed declaration/statements were introduced in C99, so personally I think that should be OK. I can't think anyone will be running a compiler on our target platforms which doesn't support it.
I'm posting this developer info here in response to a query on the xrdp-questions thread.
Should I put this on the wiki maybe?
SCP Protocol
V1 Current Status
As far as I can tell, the current state of affairs with SCP V1 is as follows:-
- SCP V1 appears to be the brainchild of a user ilsimo. This account no longer exists, in that the links to it from the commits below no longer work.
-SCP V1 was added in commit 078b4d3f4127042b020e78bb9d9762196ff070c3 by ilsimo along with the sestest utility (Nov 2006). The idea seems to have been to add a more capable protocol allowing for password changes, etc. SCP V0 was left 'as is', as SCP V1 is new and needs some work. - In commit 7c7929861246310d48789748cc150c9a4a492e09 (Sep 2008), a management sub-protocol was added to SCP V1 along with sesadmin, providing a list function and a kill function (not plumbed in).
- The last commit I can find to the project from ilsimo was 1cae42594b7d3958a6c92a201086afcbbe065fda. This was also on the same day as the previous commit but about half-an-hour later.
- There's one pretty serious problem I've found with SCP V1 (which I've shared with metalefty).
It will also be obvious to the reader that SCP V1 is pretty code-heavy and hence has a high maintenance overhead. For example, there's no need for the protocol to handle password changes. The protocol should simply be wrapping the PAM dialog and xrdp should be prompting the user as appropriate. This would also allow for proper 2FA to be introduced with barely any changes to our code.
Other badly needed system functions are reconnection and NLA. Both of these will require a dialog between xrdp and sesman. Having a simpler protocol will make it easier to get these implemented.
Next step
My current plan is to remove the unused SCP V1 code in the near future (i.e. when we get #1708 merged). This should make the existing libscp a little easier to navigate.
Future requirements
A replacement protocol needs to satisfy the following requirements:-
- Merge V0 and V1 functionality into one protocol
- Not do more than it needs to at the protocol level.
- Be simple to understand and maintain - this is critical for getting more developers involved in this area of XRDP.
- Support local authentication for management functions. An administrator should be able to disconnect or stop sessions without needing to reauthenticate.
unlink to debug. Maybe unlink needs to be retried sometime.
1 reply
I started to create FAQ page on the wiki: https://github.com/neutrinolabs/xrdp/wiki/Tips-and-FAQ
