> I think you forgot "running in datacenter X on electrical grid Y in > country Z on the planet Earth in the Milky Way galaxy in the > Relativistic Quantum universe." Philosophical considerations of the meaning of sameness aside, all Scheme programs run in the same galaxy. There could be a non-ironic application of having the datacenter on the stack. Docker orchestration can already make a datacenter-in-a-box. > 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. I didn't know the history. Anyway, setting USER means people can trivially lie about who they are. For the password database, only the sysadmin can change that (though users can still use an LD_PRELOAD hack to override those routines on most installations, and Scheme is powerless to stop that). Continuing on the "ban setuid" theme, this just shows that user information should probably be served by a daemon through a Unix-domain socket too :) Some systems have 2^32 UIDs now, though 2^15-1 is probably the safe portable maximum. I looked up the maximums for the popular systems for one program. > Interesting, but I don't think it matters. The important consideration > is whether this is a raw or block-structured device. I don't understand that. That FreeBSD link says "Block devices are disk devices for which the kernel provides caching. This caching makes block-devices almost unusable, or at least dangerously unreliable. The caching will reorder the sequence of write operations, depriving the application of the ability to know the exact disk contents at any one instant in time." Do you mean users need to know whether read/write on a byte granularity is possible, or whether users should do block read/writes with a particular block size? Not sure whether FreeBSD requires disk reads to be a multiple of 512 bytes, but all the talk of caching suggests it may not matter. > 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. It's true that errno often leads to baffling error messages. But it's still the default thing to use and I think we should give access to those values. It can and should be supplemented by contextual information (such as the name of the syscall that failed) but I don't see why we should throw it away altogether or bury it in the internals. libexplain is a very neat idea but the implementation is huge: <https://github.com/Quuxplusone/libexplain/tree/master/libexplain-1.4/>. If we provide the name of the failed syscall to go with each errno, it'll be easy to plug in something like libexplain after the fact. > Yes, well, failing to drop privileges can be a disaster. The failed setuid() will raise an exception in Scheme. That will error-exit the program right there unless the programmer committed the sin of ignoring errors in a program that runs as root. > The couple of setuid programs needed on a system (su and sudo > > 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. Instructive. ping needs raw sockets to send ICMP echos. Newgrp seems similar to a restricted version of su. I'd probably file the others under historical design mistakes that should be replaced by privileged daemon + unprivileged client. That unprivileged users can start programs to frob the user database seems particularly worrying. The fundamental problem is that a setuid program needs to clean up a staggering array of system-dependent things to make sure nothing bad can happen. The right way to "clean up" is not to make a mess in the first place, by starting a daemon in controlled conditions via daemontools / runit / systemd. Daemons should only be started by sending a start command to a persistent supervisor like that - starting from whatever environment happens to be in the shell currently = things bound to go wrong in a non-reproducible manner.
