Lassi and I started talking offline again, probably by accident.  Here's parts of that conversation: there may be other relevant stuff, but this is the best I can do today.

On Fri, Aug 2, 2019 at 2:42 PM Lassi Kortela <xxxxxx@lassi.io> wrote:

user-login-name) is reliably accomplished via (user-info:name 
(user-info (user-uid))).

In the beginning, yes: one username, one uid.  But the number of users grew faster than the number of possible uids (which was 256 for a long time) and users routinely shared uids for a while.  The LOGNAME and USER variables were invented to solve that problem.  Nowadays there are 64K uids and few systems have more than a few real users anyway.  But I agree: flush it.

Precis of block device discussion: flush it, stick with directory? and regular-file? easy-to-use procedures.

Agree about system-name (should it be the fully-qualified or short 
hostname)?

It's whatever the kernel says, which is very variable.  And nobody cares.
 
It's a good thing that isn't done by a syscall. Likewise, it's probably 
good that PATH is interpreted in userland.

Well, I meant standard library routine, really.  Posix doesn't distinguish between syscalls (man 2) and library routines (man 3).

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.

I'd rather not.  The errno compacts the whole universe of possible errors into about 7 bits.   See <http://libexplain.sourceforge.net/lca2010/lca2010.pdf> (about libexplain, which is a truly great library) for what users really need to know.
 
Precis of further discussion:  libexplain is huge, but you are only supposed to link the syscalls you actually use per code inspection or strace.  What this is about is letting *implementation-level* condition objects encapsulate the errno in a universal way.  I think we want to stick with the R6RS/R7RS rule that any object can be a condition object:  R6RS defines a complex set of them, but doesn't make its use mandatory by either users or implementations.

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

Yes, well, failing to drop privileges can be a disaster.  Most programs rely on the filesystem and the limits on what non-root users can do to avoid going nuts.

Further discussion: the final setuid call will raise an exception, so the program will know it's in a borked state.  I withdraw my point.
 
The couple of setuid programs needed on a system (su and sudo; are there 
any others at all?) 

ls -l /bin /usr/bin | grep '^-rws' shows mount/umount/fusermount, ping/ping6, at, chfn, chsh, passwd/gpasswd, and newgrp, all administration or self-administration tools.  I'd never heard of the last one, pkexe, which lets you execute a program as another user, but a little less crudely than su <name>.  It's a FreeDesktop PolicyKit thing. 

Further: Most of these are admin or self-admin tools.  Some talk of having a userinfo get/set daemon accessible by a Unix socket.  Lassi and I agree that setuid Scheme programs are a Bad Thing because of audit concerns.



On Fri, Aug 2, 2019 at 4:33 PM Lassi Kortela <xxxxxx@lassi.io> wrote:

> In the presence of LD_PRELOAD, [privileged Unix sockets] doesn't matter, because you can 
> trivially rewrite the arguments to socket() to point to some bogus 
> socket in the bad guy's home directory instead.

You're right. This just goes to show once again the old truism that all 
computer problems can be solved with another layer of indirection :)

> Nowadays the real protection boundary is the machine and what matters is not what socket you can open, but what data comes in on it. 
 

That's essentially the official stance of OpenBSD, so you are in good 
company.

> It's more about whether sub-block writes actually happen or is buffered 
> in the kernel.  But with buffers in the disk controller and in the disk 
> itself, plus SSD disks, it probably doesn't matter.

This I/O buffering mess is starting to resemble the national debt :D If 
you have a job to get done, just add another layer.

 It would certainly require exceptions to be 
at least lists, vectors, records or similar.

Great big mess there, very unlikely that any such uniformity would be adopted by Schemes.  Standardizing exceptions need to be purely predicate-based: this is the kind of exception you have, but no portable way to create a system exception.

I can't find mention of that leeway in the SRFI text - is it from R7RS?

It's in both R6RS and R7RS.  The standard R6RS condiion library is not mandatory for users, but many standard R6RS procedures are required to throw a specific condition type (must be an R6RS record, must be a subtype of the standard &condiion record type), which existing implementations were mostly unwilling to accept.  I think some R6RS bolt-ons now have two kinds of exceptions, native and R6RS, with different catchers.  Double ugh.
 

> You are only supposed to link the parts [of libexplain] for the syscalls you actually 
> use (as determined a priori or by systrace).

That doesn't seem very reliable. But I guess the worst outcome is the 
one you get by default for all syscalls when you don't use libexplain - 
it just falls back to the normal cryptic errno-only message :)

>     That unprivileged users can start programs
>     to frob the user database seems particularly worrying.
> 
> Well, some things like the full name and the shell *should* be under the 
> user's control, but are used so rarely that running a daemon makes 
> little sense.  Dynamic daemons may be enough to resolve this.

The user probably should be able to change those fields, but there needs 
to be a gatekeeper and setuid is the least reliable gatekeeper in all of 
Unix. The the same daemon could read and write the user database, and it 
could be tiny. Things like NIS lookups could also be rolled into that 
daemon (it'd fork unprivileged subprocesses to do lookups and cache the 
results). Then again, there's probably some kind of local 
denial-of-service thing that could be done by exploiting the caching.

 > So would separating /etc/passwd into critical and user-tunable files.

This sounds like a good idea. We already have the separate shadow 
password file with the actual password hashes.

It could even be a directory:

/etc/passwd/0/username -> file that contains "root"
/etc/passwd/0/fullname -> file that contains "Charlie Root"
/etc/passwd/0/shell -> symlink to /bin/sh
/etc/passwd/0/gid -> 0
/etc/passwd/0/supplementary-gids -> file of integers

Ugh, any recommendations for a good email client? I've been using 
Thunderbird all this time and it has a plethora of problems. If my mails 
look weird, that's why.

All my email addresses have been Gmail for many years now, so no.   You can use any client with IMAP capability for Gmail, but I don't bother.

 John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Take two turkeys, one goose, four cabbages, but no duck, and mix them
together. After one taste, you'll duck soup the rest of your life.
        --Groucho