I think we can now use a file browser app with relative safety. Just
give it inargs permissions, and provide a top-level directory at the
commandline to gain access to everything under it.
I'm not quite sure how to think about asking for permissions with
respect to my red/orange/green color codes. On the one hand, it seems
safer than many alternatives. On the other hand, it's liable to lead to
fatigue and blindly allowing apps to do stuff. For now I consider ask to
be orange. Ask + network allowed = red in summary, though it's orange on
the permissions screen since there's more space to convey nuance. Then
again, nobody may heed the nuance. The summary up top on the permissions
screen is definitely still a work in progress. And there's a
chicken-and-egg problem here: I can't really get a good feel for
real-world bugs in the permissions screen until _other programmers_ are
building apps to use the permissions screen, but they're almost certain
to have a crappy time of it.
I considered introducing a primitive called ask() in the Lua
interpreter, but it doesn't really make sense to validate it and so on.
I'm also not really supporting mixing Ask with other features so far.
This is a major step towards turning my permissions screen into
spaghetti; monitoring closely.
Computer owners shouldn't get in the habit of trusting app authors
regarding permissions. But they have to trust somebody, and they already
trust the Teliva platform if they are running it.
Teliva's model doesn't include any way to change directory. We just have
relative paths and absolute paths. Relative paths should not be able to
reach into parent directories.
The current test is a bit hacky; it also disallows directories ending in
a period. Hopefully not an issue.
This serves two purposes:
- Things get confusing if function being defined doesn't match the
definition name. Displaying the current definition helps diagnose this
situation.
- We're already able to see callers at a glance even if the cursor is
below the fold. The name of the current definition is arguably more
important in that situation.
This reclaims all the slowdown in sieve.tlv, and it also is now smart
enough to detect calls to global bindings that pass through variables.
On the flip side, we lose names for non-globals. But that's not very
useful anyway in Teliva's context.
This is still not enough to detect callers through coroutines
(intervening anonymous functions), though.
src/ldo.c now has a minimal diff with Lua 5.1.
It might be a bit slower than it was before, but not noticeably so..
This approach doesn't support indirect calls.
It's a mess. I calculate call-graph depth one way and calculate caller
names another way. At least one of the ways fails to work with indirect
calls. Hopefully the other way works?
There's a separate open question here of where Teliva should store files
like teliva_editor_state and teliva_editor_buffer. One school of thought
is that apps should never be dropping crud into people's directories. On
the other hand, I'm kinda encouraging people so far to just run apps
from Teliva's directory. Perhaps that makes it ok?
We're now back to the problem of how to transparently allow Teliva to
create temporary filenames without every app having to explicitly allow
them.
I think I may need to define start_writing in C, so that it can use a
non-sandboxed version of io.open.
The trouble with os.tmpname() is that it always creates in /tmp.
If /tmp is in a different volume from our real filename, os.rename()
will fail.
This new primitive doesn't support primitive paths yet.
I'm also again nervous about the security implications of my whole
approach. What if we create an inner function called start_writing?
Would we be able to do anything inside it? I'm starting to suspect this
whole approach of going by caller name is broken. An app could also
create inner functions called 'main'..
We now have a notion of libraries that we load after app code, to
prevent them from getting overridden.
Should I just load all libraries after the app? There might be value in
allowing apps to override library functions. Disallowing that too much
may be going against Lua's dynamic nature.
The interface for apps looks much nicer now, see 'main' in zet.tlv.
However there are some open issues:
- It can still be confusing to the computer owner that an app tries to
write to some temporary file that isn't mentioned anywhere.
- File renames can fail if /tmp is on a different volume.
- What happens if an app overrides start_writing()? The computer owner
may think they've audited the caller of start_writing and give it
blanket file permissions. Teliva tunnels through start_writing when
computing the caller. If the app can control what start_writing does,
the app could be performing arbitrary malicious file operations.
Right now things actually seem perfectly secure. Overriding
start_writing has no effect. Our approach for loading .tlv files (in
reverse chronological order, preventing older versions from overriding
newer ones) has the accidentally _great_ property that Teliva apps can
never override system definitions.
So we have a new reason to put standard libraries in a .lua file: if
we need to prevent apps from overriding it.
This feels like something that needs an automated test, both to make
sure I'm running the right experiment and to ensure I don't
accidentally cause a regression in the future. I can totally imagine a
future rewrite that tried a different approach than
reverse-chronological.
Perhaps this is a bad idea. It feels arbitrary, what methods Lua happens
to include in string and table objects without having to go through the
respective modules.
When should code go in the template used by new apps vs the .lua files
distributed with Teliva?
- from a privilege perspective there's no difference
- from a compatibility perspective stuff in .tlv will not get upgraded
with Teliva.
- for me the maintainer, functions in .lua files are easier to upgrade
in a single place.
- for the reader of an app, functions in .lua files will not show up to
be edited. They can still be overloaded, but the current version isn't
as discoverable. Putting something in the app is a slight nudge to
readers that they're encouraged to mess with it.
- Stuff in .lua files can use local functions and so have more internal
complexity. Apps can also hide details within functions, but that'll
make them more likely to run into limitations with Teliva's editing
environment.
I'm not yet sure how to reason about the second point in practice.
- Stuff in .tlv files I don't have to worry about compatibility
guarantees for.
- Stuff in .lua files I _do_ have to worry about compatibility
guarantees for.
Perhaps this means I'm doing things exactly wrong in this commit?
Functions like map/reduce/filter/append seem more timeless, whereas I'm
still just feeling my way around with start_reading and start_writing.
We'll see. For now I'm ruled by the fourth point. Messing with tasks and
the scheduler is much more advanced than anything else in template.tlv;
it seems to make sense to add some friction to modifying them.
Bottomline: Complex sub-systems go in .lua files. Simple, self-contained
definitions go into apps. Both are probably equally burdensome now from
a compatibility perspective.
Kartik K. Agaram