You are preventing Group users from eXecuting your script by removing the x. I think you wanted chmod 755 reading_room.tcl
Same for the db file where users of the same Group are not allowed to Write. Finally, I think locking may be a problem: users will run the script, which will create journal files as them, and then others won't be able to write to the db until the journal files are removed? Wout. On Sun., Jun. 9, 2019, 11:38 p.m. Markos <mar...@c2o.pro.br> wrote: > Many thanks to Luuk, Adrian, Graham, James, Simon, Richard and Peter, > > To guarantee "some" protection to the files containing the database I > decided to use the following strategy: > > I created, as root, the directory /home/reading_room > > And activated the "sticky bit" of the reading_room directory with the > command: > > chmod +t /home/reading_room/ > > And transferred, the files to the new directory with the following > access permissions: > > reading_room.tcl rwxr--r-x (owner markos) > > reading_room.db rw-r--rw- (owner markos) > > > This way other users can run the reading_room.tcl program but can't but > not edit it. > > And can't delete the files (.tcl or .db) > > Trying to protect against Murphy, but not Machiavelli. (As Richard said.) > > Thank you, > Markos > > Em 26-05-2019 23:33, Adrian Ho escreveu: > > On 27/5/19 12:43 AM, Luuk wrote: > >> On 26-5-2019 13:52, Adrian Ho wrote: > >>> On 26/5/19 7:49 AM, Markos wrote: > >>>> I made a program (reading_room.tcl), with Sqlite running on Debian 9, > >>>> to control the books of a reading room. > >>>> > >>>> I implemented an authentication system for common users and > >>>> administrator users in the reading_room.tcl program. > >>>> > >>>> Now I want that any user logged in the Linux be able to run the > >>>> program reading_room.tcl, which will access the database (books.db) > >>>> > >>>> But I want to protect the file books.db so that only the the program > >>>> reading_room.tcl can access the books.db file (to read or write). But > >>>> that no user could delete or write to the file books.db (only the > >>>> program reading_room.tcl) > >>> The standard Unix permissions/ACLs architecture doesn't support this > use > >>> case directly. > >> Can you give some more information on this, because it seems to work > >> as i excpect it to: > >> > >> Database is 'owned' by user 'luuk', trying to access via 'luuk2', both > >> users are in the group 'users': > >> > >> luuk2@opensuse1:/home/luuk/temp> whoami > >> luuk2 > >> luuk2@opensuse1:/home/luuk/temp> ls -l test.sqlite > >> -r--r--r-- 1 luuk users 8192 May 26 18:34 test.sqlite > >> luuk2@opensuse1:/home/luuk/temp> sqlite3 test.sqlite > >> SQLite version 3.28.0 2019-04-16 19:49:53 > >> Enter ".help" for usage hints. > >> sqlite> select * from test; > >> 1 > >> 2 > >> sqlite> insert into test values(3); > >> Error: attempt to write a readonly database > >> sqlite> .q > >> luuk2@opensuse1:/home/luuk/temp> > >> > > 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. > > _______________________________________________ > > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
