On 5/27/19 9:16 AM, Simon Slavin wrote: > On 27 May 2019, at 3:33am, Adrian Ho <ml+sql...@03s.net> wrote: > >> The OP wants *all users* to be able to update (write) the DB via the Tcl >> script reading_room.tcl, but *not* by (say) running the SQLite shell or >> something else. In your setup, as long as a specific user has write >> permissions, *every program* the user runs can write to the DB. > Some work in this thread has been because the file is a SQLite database. But > it's not really a SQLite question. It's more about the access/permissions > model of Debian 9. What OP wants can be reduced to a simpler situation: > > "I have a text file. It's on a computer running Debian 9. I want to make > sure that this text file can be read/written by multiple people, but that it > can be read/written only using this program I wrote." > > I've never used Debian so I can't solve the problem. But from what little I > remember of Linux, one solution is to create a special account for that one > operation, and set up that account in a non-standard way.
Actually, It can be an SQLite question, as another way to solve the base problem is to do something to the database so that only 'authorized' applications can access/modify it. One way to do that is to use the SEE extension and encrypt the database. If you do that then you no longer have the equivalent of a 'text file', so unauthorized applications can't access the file. It isn't perfect protection, because someone still will have the ability to delete/overwrite the file, to protect from that seems to need the protection method you describe, but if you are only trying to protect against Murphy, and not Machiavelli (as the saying goes) it may be a viable, and portable, solution. -- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
