Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 08:23 UTC
Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 12:38 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 17:43 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 18:41 UTC
(missing)
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 19:53 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 20:00 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 20:44 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 21:22 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 21:24 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 21:50 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 21:28 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 22:02 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 09 Aug 2019 21:40 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 09 Aug 2019 22:25 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 09 Aug 2019 22:53 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 10 Aug 2019 01:33 UTC
Unix logging systems Lassi Kortela 10 Aug 2019 08:19 UTC
Re: Unix logging systems Duy Nguyen 10 Aug 2019 11:00 UTC
Re: Unix logging systems hga@xxxxxx 10 Aug 2019 11:47 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 20:50 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 21:39 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 22:42 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 22:55 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 03 Aug 2019 02:51 UTC

Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 18:41 UTC

>     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.