You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have a problem when people use the 'nodev' attribute on mounts, and of course people love to lock down the system so nothing can be done with it so we should:
use getentropy or getrandom everywhere ... ;-)
What follows is a bad design that it turns out doesn't work: =)
create a new SocketPolling thread and start it in coolwsd
in that thread open /dev/urandom for reading in coolwsd
open both the above FIFOs for writing, and add them to the socket-poll
when we get a chance to write, read from /dev/urandom (non-blocking) and write to either of the output pipes.
FIFOs ensure that only one opener at the other end gets each chunk of data, and all should be well emulating these simple devices this way.
Then we should drop CAP_MKNOD and the problems that come with this like this:
kit-1559279-1559279 2024-04-03 21:58:48.464008 +0000 (Wed, Apr 3 22:58 BST) [ kit_spare_002 ] INF Failed to create random device via mknod(/home/collabora/jenkins/workspace/github_online_master_debug_vs_co-24.04/jails/1559122-f990635c/LehhVRoWIizOoS5H//tmp/dev/random). Mount must not use nodev flag, or bind-mount must be enabled: Operation not permitted| common/JailUtil.cpp:360
The text was updated successfully, but these errors were encountered:
Quite possibly we need to either patch NSS, or require a working 'getrandom' system call - which dates from October 2014 - so - surely must be widely deployed.
Ok - so then the problem is that glibc is badly out of date with kernels - and only just got getrandom. So we need to either use the system-call directly - or - I have a better idea - which is to share a single file-descriptor to /dev/urandom between all our Kit processes =)
We currently have a problem when people use the 'nodev' attribute on mounts, and of course people love to lock down the system so nothing can be done with it so we should:
What follows is a bad design that it turns out doesn't work: =)
FIFOs ensure that only one opener at the other end gets each chunk of data, and all should be well emulating these simple devices this way.
Then we should drop CAP_MKNOD and the problems that come with this like this:
The text was updated successfully, but these errors were encountered: