>From: Lassi Kortela <xxxxxx@lassi.io>
>Date: Friday, August 02, 2019 1:42 PM

>> [...]

>>> [ I suggest flushing ] 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.

Oops, I left out of my first insomnia inspired message removing *all*
of 3.6, User and group database access, that was why I later added
back a direct group-info:members procedure.

Except now that you point it out, we should also include a single
direct call that returns the home directory, that's the only other
thing that's really important in that section, not counting uid which
is provided elsewhere and desired for filesystem browsing as well as
dangerous stuff.

Unless any of you can think of sufficient 80/20 reasons to browse
other people's accounts, or find out who's in X group, etc.??

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

Especially with John's suggestion to keep file-info-regular?, I'm
thinking of doing this in an inverse fashion, only providing
predicates for the file system objects that are relevant to the
putative user of this SRFI, i.e. regular files and directories.

A user doesn't need to know what /dev/random etc. is, besides failing
both dir and file predicates if he chooses to check.  If /dev/null is
a regular file, well, he can test that before filling up that
filesystem (forget whether that accident was due to it going poof or
misspelling it).  The Windows examples would also be satisfied with
that, correct?

> [...]

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

It's a *colossal* can of worms, my last Lisp project in anger, a
Clojure website for a non-profit I was volunteering for a few years
ago, had to deal with them, but only the US ones.  I haven't even
found a POSIX way to return the current time zone as a string,
although I haven't looked very hard yet.  Scsh doesn't do either.

> [...]

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

That's a bit messy to do portably as we're doing it now, seems the
strategy is to make them high numbers.  A problem this current POSIX
SRFI has is that it has to use the official ones, so errno-error will
return a sane string.

That's pretty much been fine so far for my Chibi Scheme
implementation, e.g. struct finalizers are totally fragile and
"return" SEXP_VOID, so I just put the "is this DIR still open?" etc.
error checking logic one level above, and return the official POSIX
errno that's supposed to be returned.

More serious thought resulting in a separate SRFI that can be used by
*lots* of other SRFIs and code sounds like a capital idea to me.

> [...]

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

Which I use religiously in my /etc/fstab files, and OpenBSD does so by
default.  But all that said, *we* can't prevent someone from setting
their binary set-uid root.  We *could* view giving them setuid
etc. calls in this base SRFI to use after doing high privilege stuff
as encouraging them to go down this dark path.

> [...]

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

I can certainly see people doing that sanely.  We do after all live in
a world being taken over by systemd, I'd take a Scheme daemon over
that any day.

> In any case, this falls under the banner of "security" more than
>"general OS APIs" as the security implications are much more serious.

That's worth thinking about, but I'm not sure how to structure that as
an SRFI, vs. a cross cutting concern.  A *pervasive* concern.

> [...]

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

Eh, sure.  "Harold Ancell"

- Harold