This is what the UNIX group ID and the set-group-id capability is for. You make the files readable (or read and write) by a group (mode 640 or 660).
You make the program that controls access to the files set-group-id to that group. You may need a small "C" wrapper program to run the script set-group-id depending on the version of UNIX and security settings. Allowing scripts to run set-group-id has at times been violently controversial, and I have not bothered to track teh state of teh art. On Mon, May 27, 2019 at 8:37 AM Richard Damon <rich...@damon-family.org> wrote: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
