Miscellaneous Linux ideas

You would need to disallow ".." for this to work.

This way we can start a filesystem and access it, and keep it private without creating a mount namespace

(this is essentially possible with the new mount API)

Instead of mounting in the kernel, just let a process multiplex between a set of dirfds that it has access to.

This allows doing very fancy policy, without paying the cost of that policy in the kernel.

We need some way for a userspace program to implement a dirfd.

Both FUSE and 9P have the problem that you can't return an arbitrary FD from, say, an openat call. So you couldn't return a socket, or a dirfd for another server. If you wanted to return such things, you'd need to stick around as a proxy in the middle, which reduces your opportunities for abstraction. In other words, you want to be able to do introduction rather than proxying.

So a new way to implement a dirfd is needed. It would be nice if it didn't even require mounting a filesystemm.

One way is described in the next section: file descriptors backed by uploaded in-kernel eBPF programs.

If a file descriptor is proxied by an eBPF program, that program can hold some extra FD which it monitors for shutdown commands; this gives us revocability.

This would also work if userspace processes were able to emulate arbitrary file descriptors, but an extra roundtrip to userspace for every file access is pretty heavyweight.

One could have a type of fd which communicates with a remote server, transparently proxying each syscall to an fd on a remote server. Then a local program could operate on remote resources just by being handed an fd for a remote resource.

ssh can work for this purpose. There's also s6-sudo and systemd-run, but I think ssh is the most plausible way to do this, since it's very popular and powerful already.

How do we inherit our current environment, while mutating it in some way that requires privs? This currently uses setuid

example: unshare

We have cgroups but 1. the API sucks, 2. they're privileged

I still hold out hope for something integrated with the traditional process tree, or at least something informed by a FD-api for processes

(I did this with supervise)

Having separate process supervisors hurts flexibility; I want to be able to start debugging a program started in my shell, or access stdin/stdout of a program started by my init system, or so on. Attaching to pids is not a solution; a sane model for ownership of processes is needed.

Perhaps they should be a single program.

Better yet, perhaps an FD api would allow sharing ownership; or even borrowing, and revocability.

Or possibly it should be possible to move/share process ownership between the programs; an FD API could allow that.

(This is in the kernel now: pidfd)

PLASH-style

Python-notebook-style revision of commands and idempotency

traditional sh/bash is just not a good language

this might be difficult to do at the same time as adding new features; maybe backwards compatibility is useful, and tolerable if new features are added in a clean way?

Python (and other languages) notebooks are very powerful interactive workspaces

seems like a natural design to steal for improved shells

It will make a lot of the work easy since it's already done, and it's already got built-in remote support.

but it is controversial.

Possibly support a new convention for a passed-in FD, "stddisplay" or "stdgui", on which a tool can send and receive GUI information?

Of course this is just the same as DISPLAY in X or WAYLAND_DISPLAY in Wayland.

Python? C++? OCaml?

I want something with the fluidity of Go, which achieves it through using Linux kernel APIs and syscalls to the maximum degree possible.

(This is now rsyscall)

Likewise with containers, I guess.

(Emacs kind of already does this with TRAMP. And someday I'll write an rsyscall library for Emacs…)

A userspace daemon accessible over IPC, which responds to requests by returning a setuid executable owned by an unused UID which does nothing but execvp its arguments.

The holder of one of these executables can then switch into that UID. The executable is basically the capability to switch in the UID, reified.

This means the setuid bit will stay around. Maybe restrict it to root?

How to garbage collect these users?

The old standby that everyone seems to want. Some new kernel capability which lets an arbitrary user subusers which they can su to.

It's easier with users being defined by strings rather than UID numbers; you can just allow a user to append "/anystringlikethis" to their username

Kind of like Kerberos. Is it possible for principals to create subprincipals? I don't think so, but maybe it could be added

Users are a stupid concept anyway, we want an object-capability system. So just a prctl which lets you relinquish the authority of your UID?

How can you use the fileystem without a UID?

Maybe just pass 777 dirfds around?

And pass subdirs around if you need to give access out?

Reconstructing an ACL system in the absence of UIDs would be helpful for user expectations. Maybe if UIDs were reified into a capability you could use to access the filesystem? that's kind of like the setuid idea

Kerberos won't work, it requires trusting each box. We want a box to be able to join without everyone having to trust that box.

Trusted community/university computing organizations can have certs, which can sign certs of new users to give them access to the cluster

LDAP sucks, and it's centralized anyway, and hopefully we'll get rid of UIDs eventually anyway

It should be possible to bridge a machine into the network automatically, without requiring any human intervention.

Continuing administration should also be as small as possible.

Each box can do authorization and accounting in its own way. Not sure about this though

It only makes sense if this is the case. This excludes the admins.

There's lots of stuff possible unprivileged, you can even run KVM-accelerated VMs unprivileged.