about summary refs log tree commit diff stats
path: root/src/teliva.c
Commit message (Collapse)AuthorAgeFilesLines
* bugfix: policies must end in newlineKartik K. Agaram2022-01-021-3/+3
| | | | I believe kilo kinda naturally enforces that. We'll see.
* start on a view of audit eventsKartik K. Agaram2022-01-021-2/+67
|
* editing file permissionsKartik K. Agaram2022-01-021-41/+54
|
* editable file permissionsKartik K. Agaram2022-01-021-48/+178
| | | | | | | | | | | | | | | | | | | | | Extremely cruddy implementation: - I'm still unclear on how to represent the advice function: - How to handle errors when loading user configuration? Currently I refuse to start. - Whole function? More errors to handle in header and so on. What if the function is renamed? - Just body? Needs more structured editing support. - Lots of duplication, particularly between the permissions in the menu and the permissions screen. I don't know how to show the hostname at the time of connect() or bind(), so networking is going to remain a boolean for now. It's also unclear what effective constraints we can impose on what gets discussed with a specific hostname. Everything outside the computer is out of one's control. One trick I learned is for consistently grabbing ASan logs on abort: It's always safe to redirect stderr with ncurses!
* fork a new editor widget for non-codeKartik K. Agaram2022-01-021-2/+2
|
* better follow kilo's naming conventionsKartik K. Agaram2022-01-021-3/+3
|
* copy tweakKartik K. Agaram2022-01-021-3/+4
|
* renameKartik K. Agaram2022-01-021-25/+25
|
* sandbox: tweaks to warning copyKartik K. Agaram2022-01-021-7/+8
|
* spacingKartik K. Agaram2021-12-261-0/+2
|
* start persisting sandboxing settingsKartik K. Agaram2021-12-251-0/+86
| | | | Zero guarantees of compatibility at this point.
* reorgKartik K. Agaram2021-12-251-24/+24
|
* file open() is now sandboxedKartik K. Agaram2021-12-251-12/+21
| | | | | | | In the process we now also have a mechanism for Teliva to overlay errors while apps run. Might make sense to make that available to apps as well. But I'm starting to realize that any app access to the Teliva areas of the screen is fraught with risk.
* flesh out very preliminary UIKartik K. Agaram2021-12-251-8/+128
| | | | | | | Our sandboxing model is a blunt caricature, just two booleans. But let's see how far this gets us. Still doesn't persist, and definitely has no effect.
* delete a couple more hacky function prototypesKartik K. Agaram2021-12-251-1/+0
|
* .Kartik K. Agaram2021-12-251-2/+8
|
* mock sandbox status and some initial colorsKartik K. Agaram2021-12-251-1/+18
| | | | | | | | Current plan: - two booleans to gate file and network access, respectively - false shows as green, true shows as orange - if _both_ booleans are true, then both show as red to indicate that there are no protections.
* fix menu colors in all color schemesKartik K. Agaram2021-12-251-1/+2
| | | | | | | | It looks like attron doesn't actually enable colors near 256, even though https://linux.die.net/man/3/attron suggests it does. > COLOR_PAIR values can only be OR'd with attributes if the pair > number is less than 256.
* reorg: pull Teliva-specific stuff out of lua.cKartik K. Agaram2021-12-251-0/+1008
It should now be easier to diff against the Lua 5.1 sources upstream.