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

Reply via email to