IRC channel logs
2026-04-01.log
back to list of logs
<lisbeths>I was in here the other night. i believe I am developing something that could be made useful for the design of writing userland daemons in microkernel architrcture <lisbeths>i ticked off the other guy cause I was talking about virus writing and he thought I was trying to hack him with my code <lisbeths>but im not a security researcher im a language designer <lisbeths>basically I have this shell program that has completely flexible notation at runtime <lisbeths>so that you can extend the syntax how you want <lisbeths>and I have another shell program that is a very tiny jit compiler for making very small microprocesses for highly paralell daemons <lisbeths>and I use the flexible syntax to define languages that compile to that jit interface <lisbeths>the whole thing is <1 k of source and is architecture agnostic <lisbeths>the downside is it can only run in userland, it cant run in the kernel <lisbeths>but I think it would be really useful for userland components of microkernels <jab>lisbeths: you should write up what you just talked about in an email. Send it to bug-hurd@gnu.org and probably provide a link to your code. <youpi>did you choose the date on purpose ? ;) <youpi>ah, yes from the text indeed :) <dionysos>well the announcement is only half april fools joke <dionysos>the image works, and we rebuilt already ~90% of the system set natively in qemu <dionysos>gcc and glibc failed due to missing swap, but that should be fixed now <dionysos>lots of minor error messages in bootup scripts etc but the essentials are there <azert>Gentoo GNU/Hurd! What, that was so fast! <azert>youpi: I have a few questions about Hurd task ownership, and the Hurd way of implementing the classic posix security model, if you don’t mind answering a few ? <azert>looking at old conversations on the wiki, it looks like <azert>not sharing the task port on file open is a deliberate choice <azert>hence the lookup retry magic for /proc/self <youpi>yes, the application could actually be using different auth ports to open a file <youpi>so we wouldn't want to use "credentials" of a task, but let the task give the credential it wants to use <azert>now the question is if it wouldn’t still be useful to share the pid, not for credentials, but to allow a filesystem to give a different answer to different processes. In a way the lookup magic already allows that but in a weird way <youpi>why not letting the filesystem return a magic retry ? <youpi>the problem with sharing the pid is that it's the start of possibly trusting it, which would be wrong <youpi>I understand you don't ask for using it for credential, but the rope is sloppy <azert>the issue with the magic entry is that it is very easy to manufacture hence lie to the filesystem <azert>with pid, it would be the same <azert>but with pidfds, it would be quite more interesting <youpi>yes you can lie with the magic, but that's up to the client to lie to itself <youpi>pidfd could be provided by e.g. proc, but do we need to trust that for path lookup? <youpi>what is the actual use case ? <azert>as a detour of implementing process cpu affinities, I got carried away with the fantasy that cpu sets could be thought as containers that can be virtualized and are seen by the tasks as the whole system. That’s not the case, but it could be modified to be like that quite straightforwardly <azert>then I looked into /proc/cpuinfo <azert>and the way it could be done now is by using the magic to look into /proc/self/cpuinfo <azert>but that wouldn’t be containerized, you could just modify self with whatever <youpi>lying to applications like that leads to users getting surprised <youpi>in terms of numbering, they'd expect to know that they are not running with cpu0 allowed <youpi>i.e. have a set of allowed cpus, and cope with that <youpi>saying that some container has another notion of cpu0 leads to user confusion <youpi>and masking cpu0 from cpuinfo can lead to application confusion <youpi>the pragmatic approach is to expose the api for applications to know what they can use, and expose that through getaffinity, and applications will behave <azert>I agree, and I desisted. But that was my use case <azert>I suspect one could come out with silly file systems that play with users in other ways <azert>and I’m not sure we want that <youpi>you mean that they would return a magic pid retry just for fun? <youpi>we could make glibc not follow magics of untrusted filesystems <sam_>azert: thank you! quite proud of it