zet.tlv: switch file writes to new API
commit38063812b6e931740f9d9d7b4bc95429dcfb3aa6
authorKartik K. Agaram <vc@akkartik.com>
Mon, 7 Mar 2022 18:35:23 +0000 (7 10:35 -0800)
committerKartik K. Agaram <vc@akkartik.com>
Mon, 7 Mar 2022 18:55:18 +0000 (7 10:55 -0800)
tree3d71c8c5dba878c99551aebbba760a4c4e0deab7
parent7a315e3d9f1c668b54d57b472b612c7f6d738ede
zet.tlv: switch file writes to new API

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.
src/liolib.c
src/teliva.c
src/teliva.h
zet.tlv