Den fre 31 jan. 2020 kl 11:48 skrev Andrew Easton <[email protected]>:
> On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote: > > On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote: > > > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen < > [email protected]>: > > > > > Properly starting up a daemon process requires several steps, > > > > > often involving unveil(2), pledge(2), chroot(2), prviledge > > > > > dropping, sometimes fork+exec for privilege separation, and so on > > > > > > > > The process I need to run is written in Clojure and thus runs on the > > > > Java Virtual Machine. Do you have any suggestions on how to best go > > > > about making it "daemon-like"? I am not sure that I can call > unveil(2), > > > > pledge(2) and chroot(2) from Clojure without some strange sorcery. > > For the record, I am also interested in information on how pledge(2) and > unveil(2) would interact with a "higher level language". man OpenBSD::Pledge will show how you call pledge from perl (if you accept that as a higher level language in this case), and it works mostly because perl will not silently have tons of secret underlying operations so that when you ask perl to concatenate two strings, it will not open sockets and pipe them to itself in order to do that, or write them to $TEMPDIR or some other possible construct in order to make a simple operation suddenly require file system access or socket binding capacity. The more weird (or generic) your runtime is, the less chances will you get to be able to say "from now on, I will not open any more files, sockets or call reboot()" because the runtime may just do one of those, when garbage collecting or something. > I would also > be happy to learn more about how they interact with assembly. > I'm sure they interact equally well as with C, given that the C program that calls pledge/unveil at that time is assembler. > Concretely: > Just to start off easy, how can I find conceptual documentation on > what an operating system "process" is in OpenBSD and how deeply a libc > is tied into that by design? As far as I am aware a process has the > libc isn't all that tied to a process, it's just that libc contains some very neat and useful functions (like wrapping calloc() over malloc()/mmap() so the kernel only exposes one single way for a process to allocate memory, but libc can still implement realloc(), calloc() and so on for you, using normal code and the give-me-some-pages-of-RAM syscall. > "current working directory" associated with it, in order to be able to > resolve relative paths and is also where "environment variables" are > stored. Well, you can still reach the environment without libc, but libc makes it easier for you, just like with the something*alloc() routines. > > (I am also still fuzzy on how intertwined an operating system and a CPU > are. From my superficial understanding, e.g. the operating system has > to be aware of the MMU. I think that is a completely separate dimension, but yes, given that the OS controls and commands the MMU to do various things, it most certainly is "aware" of it. -- May the most significant bit of your life be positive.
