> One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways.
This is an interesting offhand comment. You could implement a very similar tool by SSHing to localhost.
replies(5):
Looking at the design, I found it to be sort of messy.
You could restrict commands ssh could invoke, but it didn't seem super secure.
Also scp/sftp was not well designed. You basically had to give ssh access to your system to allow a file to be copied, and there were no real path restrictions.
I personally thought ssh could be much more robust in what you could run and what you couldn't. And scp/sftp could have better filesystem semantics so you could have more security in what you could access.
And I thought having a write-only scp would be really interesting, sort of like a dropbox for people to send you files securely, but not have to give someone ssh credentials to do it. And an anoymous scp/sftp for distribution or a dropbox could have been really interesting too.
The write-only scp intrigues me. I guess it's not hard to write a program to do that. But, right, that's not easy with standard tools only. The Linux file system was also not designed for that (although it doesn't prohibit such software) I guess.
There's no 'the' Linux file system. There's plenty of file system to choose from.
And, in fact, it would be relatively easy to write a write-only filesystem with FUSE. (https://en.wikipedia.org/wiki/Filesystem_in_Userspace)
I think you can achieve that at the file system level. At least, a long long time ago I maintained a public server with exactly that functionality. I’ve forgotten the details now but if I were tasked with this today my first attempt would be add a sticky bit like we do with /tmp: chmod +t dropbox/
If you don’t want to allow me to delete or overwrite my own files I believe (but haven’t tested) that chattr +a on the dropbox dir would achieve that.