Least Authority rust std/core libs

[dckc]

goal: libraries get no ambient authority; all authority comes from main programs

audit for ambient authority (random, time, ...)
task local storage is global mutable state? or is it folly to try to isolate less than a task?

[dckc]

mkdtemp()
oh... and use file descriptors rather than paths

[dckc]

rust rt/args has a FIXME for args (which are ambient authority)
rust-lang#7756 Better way to store command line arguments?

TODO: find the haskell compiler history around global args and how it prevents parallel compilation or some such.
found the discussion from 2012-08-09 #haskell http://ircbrowse.net/browse/haskell?id=13957476&timestamp=1344474950#t1344474950

2012-08-09 03:20:30 +0200 DanC: http://www.aosabook.org/en/ghc.html , look for "crime doesn't pay"

[dckc]

I know that defining purity precisely can be challenging in multi-paradigm language but there is a very useful most basic notion "function that does not access any global state other than via arguments".
-- More casual hacking: Thoughts about Rust from D programmer
bookmarked Jan 14, 2015
https://diigo.com/07w9dk

[dckc]

see also rust-lang#3094 (comment) Non-determinism as an effect.

[briansmith]

Doesn't the entire design of futures.rs require ambient authority? My understanding is that all the scheduling is handled through a hidden back channel of mutable global state.

[dckc]

Yes, it does look that way:

thread_local!(static CURRENT_TASK: Cell<(*const Task, *const data::LocalMap)> = {
    Cell::new((0 as *const _, 0 as *const _))
});

-- task/mod.rs

This comes back part of my original Oct 2012 comment:

task local storage is global mutable state? or is it folly to try to isolate less than a task?

("task" back then is closer to "thread" now.)

I'm still thinking this through...

[briansmith]

It seems like this should be combined with a lint addition prohibiting static mut.

[briansmith]

https://github.com/NuxiNL/cloudlibc has some interesting ideas, such as passing the application a file descriptor to the directory/directories it is allowed to access, instead of letting it open files by path. Presumably paths have to be constructed relative to those root file descriptors.

[dckc]

Right... That's what I meant in #2 (comment):

oh... and use file descriptors rather than paths

[dckc]

tag_safe looks handy!
example: larust-tame a68fa1a0c7c5b62ab4b70124e91d519f90eb6e16

issue 1: can we use it to tag std functions?

[ratmice]

lacking an heap allocations is there actually any ambient authority in the core library?
A potential alternative to tag_safe seems to be mentioned here:
rust-lang#27783 (comment)

then building up a variation of std which just drops the file/time/randomness leaving the portions of std wanted intact
[edit] I see now that this issue predates the existence of the "libcore" library, to which i was referring to
https://doc.rust-lang.org/core/

[dckc]

right... a variation of std is what I'm hoping for:

there is renewed interst in refactoring std for ultimate portability. One result of this could be a std alternative with no ambient authority. -- my wishlist

[dckc]

More motivation:

I can share my technique for patching 'std' though in vague terms. First of all, it's pretty hacky, my goal was not to port 'std' in its entirety, just enough to get things to run. It turns out, there's not THAT much to do anyway, because there are huge swaths of things that just are impossible to port to consoles anyway, like anything to do with the network or spawning processes etc.
-- https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_kyren_from_chucklefish_we_make_and/dosn15b/

[dckc]

and more:

The standard library has many stubbed out components which (as far as I know) immediately return errors when used. For example using threads will immediately return errors (likely then causing a panic) and I believe similar functionality like TCP/UDP will also tend to return an error pretty quickly.
-- https://internals.rust-lang.org/t/state-of-webassembly-and-rust/60

[briansmith]

It would be great to somehow combine this effort with the steed effort, and/or perhaps redo steed as an incremental rewrite of the linux-musl-libc target and/or the cloud to a pure Rust libstd that removes all the stuff that is problematic with respect to this (perhaps using CloudABI as inspiration). LMK if you'd be interested in pursing any such efforts.

See also https://lwn.net/Articles/433326/, which people mentioned recently as motivation for a capability-based stdlib.

See also https://github.com/benlaurie/go-capsicum.