> Under the 80/20 rule uname should go as well, is it useful for > anything more than curiosity which can be satisfied with the uname > command, and automated bug reporting? That would finish off 3.8 > system parameters for the base SRFI. > > Agreed, flush it. Most of what's important about it is provided in > (features) in more useful form. I have a small "Environment Stack" SRFI in the works (for OS, CPU, VM identification). It's a generalization of SRFI 112: Environment Inquiry which does half the uname fields already. The idea is that you are running Scheme on top of a stack of things, and you can ask questions about each element on the stack. So as a ridiculous extreme case, something like IronScheme on Mono on Alpine Linux in a Docker container on Debian Linux on VMWare virtual machine on Windows 10 on an x86-64 PC would be a stack of 8 environments. If you asked a simple question like "what OS am I on?" if would give the innermost OS (here, Alpine Linux) but you could manually walk the whole stack. I'm still looking into how comprehensively such layers can be mapped out: that example might have to stop at figuring out it's in a Docker container, or in VMware. Needs quite a bit of exploration still. I'll be interesting to find out how much can be done without blowing the complexity budget. The motivation here is that a stack structure is future-proof against new infrastructural innovations (such as containers recently) while not making the common case (asking simple questions) more complicated for the user. > rule: user-login-name, file-info-regular?, file-info-block-special?, file-info-character-special? > > Flush all except file-info-regular?, I'd say. Often enough you want to > make sure something is not a directory or other weird thing. (user-login-name) is reliably accomplished via (user-info:name (user-info (user-uid))). In principle one can read the USER envar but that's not the most reliable thing in the world. FreeBSD hasn't had block devices in a long, long time: <https://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html>. Though the st_mode bit for block devices is still there, all devices in /dev are character devices. It might make sense to have a single "fileinfo-devide?" predicate. That'd cover Windows too (NUL, CON, PRN files). > I just checked, and Unix Seventh Edition, FreeBSD, and Cygwin all > allocate the mode bits in exactly the same way (not surprising since > they are stored on disk). They even all define the bits and masks with > octal constants still! So anyone can portably decode a st_mode despite > Awful Warnings about non-portability. I can't swear to IBM mainframes > or Windows. Still have to think more about this. > file-info-socket? and system-name belong to a networking SRFI. Agree about system-name (should it be the fully-qualified or short hostname)? Still thinking about file-info-socket?. > current-timezone and current-locale make no sense just by themselves. > > If we have them plus posix-time (all non-portable), we can do date-time > and i18n/L10n SRFIs that are otherwise completely portable. This is the > right place to put them, I think. Still thinking about this too. > home_dir matters because there is > no syscall to interpret tildes in pathnames, unfortunately. It's a good thing that isn't done by a syscall. Likewise, it's probably good that PATH is interpreted in userland. > In that case we need a third SRFI for errno errors, for the same reasons > as timespecs (but see below). I've been thinking about a separate SRFI for OS errors too. That means exceptions native to the Scheme implementation and unrelated SRFIs can supply errno values in their exceptions too. There could be a predicate (exception-get-unix-errno some-exception) which would return #f if that exception doesn't have one. > I think a process SRFI is important if we > want to encourage multi-process programs (which I consider a Good Thing). Fully agreed. > The privilege-dropping and -resuming system is a footgun (e.g if you > don't drop the group before the user, bad things) I'll just fail the other way around, nothing worse. > and should be > refactored to what setuid programs actually need. Setuid programs are one of the worst ideas in all of Unix, which is saying a lot. The security is like Swiss cheese, there are so many gotchas you can barely enumerate them all. It's so bad that several systems now have a mount option to "never allow setuid programs from this file system". The couple of setuid programs needed on a system (su and sudo; are there any others at all?) should be written in plain C and every line of code audited by experts. The canonical way to avoid the need for setuid is to run a daemon as root, and it listens for commands from unprivileged programs via a socket. Unix-domain There's now a great syscall getpeereid() to check the credentials of those sockets. Once again, a succint treatment of secure IPC options from DJB: <https://cr.yp.to/docs/secureipc.html> As for setuid() and setgid() and related system calls, those are used in daemons that start life as root. I'm not sure people should start Scheme daemons as root but I'm willing to listen to arguments to the contrary. In any case, this falls under the banner of "security" more than "general OS APIs" as the security implications are much more serious. > But the Right Thing may be not to try to run > setuid in Scheme at all, and leave that to a small outboard program that > execs you, or indeed (x)inetd if all you need is to open a well-known port. Strongly agreed. Writing setuid programs is one of those things that are only contemplated by people who don't know what they're doing. Once they learn enough to know what they're doing, they no longer want to do it. > If we do this, the new SRFI shouldn't just be a clone, it should be a > reworked high-level process control library. Both Posix and Windows > suck here, though Windows may suck somewhat less (although that could > just be my ignorance). I got the impression Windows sucks somewhat more. It's more difficult to have fine control of things like file descriptors and process IDs, which works great on Unix. > Thanks for doing all this work! I would like you to add your name (in > preferred form) to the Authors section, marked (editor). +1 Harold has been putting in a very solid effort advancing the document.
