here's xrdp development talk room, questions here: https://gitter.im/neutrinolabs/xrdp-questions
Sorry I missed this over the weekend.
@jjjedli_gitlab - I'll gloss over the discussion regarding Nessus. Your organisation has decided to use it, and regardless of whether you personally think that's a good idea or not, I can see you're in a position where that's not up for debate. I've been there myself as a syadmin in a previous life, so I understand your position.
We're well aware we're missing NLA, but implementing it requires a significant change to the architecture. This in turn needs a good understanding of the use cases xrdp applies to, and how xrdp has changed over the years as Linux authentication in particular has evolved.
Currently, xrdp consists of two processes. The xrdp process handles the incoming connection on TCP port 3389. Session management functions, including authentication are handed off to xrdp-sesman over an IPC mechanism we call SCP. SCP implements a basic 'one-shot' authentication where a username and password are passed from xrdp to xrdp-sesman, and a yes/no answer is returned. This is fine for simple usages, but not for more complex scenarios.
One of the original xrdp developers was working on improving SCP, but for undisclosed reasons abandoned both the project and it seems software development mid-implementation. I've done some investigation into historical commits, and summarised what I've found on the wiki. It's a blow to any project when this sort of thing happens, but it's not uncommon.
Essentially SCP has remained unchanged for well over a decade for reasons which I imagine you can now see. In that time, PAM has become mainstream, and there has been a lot more interest in integrating Linux with enterprise authentication systems, particularly AD.
The plan I have is to replace SCP with something else which can run over the internal xrdp transport mechanism, but more easily support two-way authentication conversations. This is essential for full PAM support, NLA, auto reconnect and some other things I won't go into.
I've kicked off https://github.com/neutrinolabs/xrdp/discussions/1961 for a couple of reasons. One is, I've been approached by an organisation which is considering sponsoring some of this work, and the other is that I don't want to do this all in my head, and then for reasons I can't foresee disappear off the scene as has happened in the past, before we've got a clear direction as a project.
NLA is a way off I'm afraid. I'm focussed at the moment on getting the basics right. It's possible that with a better documented SCP, we may be able to get more developers working on this in the future. At the moment it's a poorly understood bit of the system.
I hope that's useful. If you feel able, please contribute to https://github.com/neutrinolabs/xrdp/discussions/1961.
@metalefty - The NEWS Wiki page should be up to date for this release. I've just edited it to add the clipboard file transfer logging PR.
I've also added an announcement to deprecate running xrdp and xrdp-sesman on different hosts, so that we are able to move to UDS for this interface maybe in the April 2022 or August 2022 release. Are you happy with that?
1 reply
12 replies
The only two I can see that need to be discussed are neutrinolabs/xrdp#1692 and neutrinolabs/xrdp#1825. Is that right?
1692 is currently tagged for 0.9.17 but needs a little work to be merged. Is that something we should push for? @Nexarian - what do you think about this one?
I've added my thoughts about #1825 to the PR itself. It's a bit rough and could do with some more testing. On the other hand, the function it applies to doesn't work at all at the moment.
2 replies
1 reply
That's a very good point.
Having a proper release cycle helps to focus the mind and prioritise things. Yes, there are a lot of PRs open, but I'm hoping a lot of them can be cleared away when we get the authentication better, and when Jay and Nexarian get the GFX stuff merged.
One of the things commented on in neutrinolabs/xrdp#1971 is the issue template. You raised neutrinolabs/xrdp#1574 a while ago, but we never got round to implementing it. Do you think that's worth getting done?
2 replies
@nik:matrix.teckids.org - I've just had an automated message concerning xrdp and xorgxrdp being marked for autoremoval from testing (below)
Is there anything I can do to help you resolve this in the best way?
Thanks,
xrdp 0.9.12-1.1 is marked for autoremoval from testing on 2021-10-10
It is affected by these RC bugs:
993096: xrdp: fails to migrate to testing for too long
https://bugs.debian.org/993096
This mail is generated by:
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Autoremoval data is generated by:
https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
1 reply
Nexarian> I wrote that line, though I wouldn't necessarily call myself an expert. I'm closer to a devoted fan who has debugged XRDP with lots of blood, sweat, and tears.
https://github.com/neutrinolabs/xrdp/issues/1964#issuecomment-921331983
I'm also a devoted fan of xrdp rather than an expert. I'm not an original author of xrdp however I just volunteered to join the xrdp project because release management was very poor as I said just above. I particularly work on release management, issue triage, negotiation with distro package maintainers (picking distro patches up) and I write codes a little bit.
@Nexarian @matt335672 @aquesnel and other contributors are more experts than myself in writing C codes. I learn lots of things by reading the codes you wrote and code review.
I suddenly just wanted to say thank you. Thank you always! Let me know whenever you want extra permissions on GitHub.
3 replies
Wanted to let you all know what I've been up to recently!
Jay created a new branch of the egfx prototype a few weeks ago that enables direct memory access to the Xsession such that when you're using hardware acceleration with Nvidia all processing is done on the card until the last moment when the memory is copied out to be shipped over the network. The speed is unlike anything XRDP has been capable of before. We're talking the ability to play full screen youtube videos in spite of 30-40 ms latency over a WAN connection. Using things like Blender and other photo editing is now a realistic option.
I, true to form, have been working on adding resize-on-the-fly to it, and here's my prototype: https://github.com/jsorg71/xrdp/pull/6/files
But I could also use your help. The xorgxrdp_helper module, defined here: https://github.com/jsorg71/xrdp/tree/egfx_helper/xorgxrdp_helper seems to have a weird bug. The logging will sometimes cut out in the middle of writing a line. It looks like this:
[20210830-00:29:00] [INFO ] [xorgxrdp_helper_nvenc.c][78][xorgxrdp_helper_nvenc_init]:NvEncodeAPICreateInstance rv 0
[20210830-00:29:00] [INFO ] [xorgxrdp_helper.c][172][xorg_process_message]:100 type 1 size 4
[202
As best I can tell the system is buffering, but I don't understand why. Logs are initialized here: https://github.com/jsorg71/xrdp/blob/egfx_helper/xorgxrdp_helper/xorgxrdp_helper.c#L443
@aquesnel -- You're our logging expert, do you have any idea why this might be happening?
I can't see why this should be happening on a quick look.
The log file should be opened by internal_log_file_open() in common/log.c. This specifies O_SYNC for writes.
You could use a debugger to check the file is actually being opened here. Also, you're not using anything exotic for the filesystem you're logging to are you?
g_writeln("xorgxrdp_helper::xorgxrdp_helper_setup_log: using "
"log file [%s]", log_file);
if (g_file_exist(log_file))
{
g_file_delete(log_file);
}One way to attach a debugger to this is to add a busy-wait loop into the code. This is off-the-top-of-my head and not tested:-
volatile int attached=0;
static void wait_for_debugger(void)
{
while (!attached)
{
g_sleep(1);
}
}You can the attach the debugger, break, set the value of attached to 1, set other breakpoints, and off you go.
I think the lines you've called out above are just to make sure the log file is empty when you start. Provided it's called in the right place that is.
I figured it out. It's due to my lack of understanding of arcane unix semantics. Jay had removed this: jsorg71/xorgxrdp@ef9dbe4
Interestingly, those files he removed redirect the "execlp" STDOUT and STDERR output to those files. But those outputs weren't buffered properly.
It's also due to the way I merged the code. Anyway, problem solved. XRDP logging works.