Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #209152 > unrolled thread

How to set access permissions to protect a database file?

Back to article view | Back to linux.debian.user

Contents

  How to set access permissions to protect a database file? Markos <markos@c2o.pro.br> - 2019-05-26 02:20 +0200
    Re: How to set access permissions to protect a database file? David Christensen <dpchrist@holgerdanske.com> - 2019-05-26 05:20 +0200
    Re: How to set access permissions to protect a database file? mick crane <mick.crane@gmail.com> - 2019-05-26 05:20 +0200
      Re: How to set access permissions to protect a database file? David Christensen <dpchrist@holgerdanske.com> - 2019-05-26 06:40 +0200
        Re: How to set access permissions to protect a database file? mick crane <mick.crane@gmail.com> - 2019-05-26 07:10 +0200
          Re: How to set access permissions to protect a database file? Markos <markos@c2o.pro.br> - 2019-06-10 00:00 +0200
            Re: How to set access permissions to protect a database file? mick crane <mick.crane@gmail.com> - 2019-06-10 00:40 +0200
            Re: How to set access permissions to protect a database file? Reco <recoverym4n@enotuniq.net> - 2019-06-10 08:00 +0200
              Re: How to set access permissions to protect a database file? john doe <johndoe65534@mail.com> - 2019-06-10 10:40 +0200
            Re: How to set access permissions to protect a database file? David Christensen <dpchrist@holgerdanske.com> - 2019-06-11 05:00 +0200
    Re: How to set access permissions to protect a database file? Joe <joe@jretrading.com> - 2019-05-26 10:20 +0200
      Re: How to set access permissions to protect a database file? Dan Ritter <dsr@randomstring.org> - 2019-06-10 01:10 +0200

#209152 — How to set access permissions to protect a database file?

[Multipart message — attachments visible in raw view] — view raw

Hi,

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 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. But that no user could 
delete or write to the file books.db (only the program reading_room.tcl)

Please, how can I configure the system to do that?

How to define the permissions?

Thanks,

Markos

[toc] | [next] | [standalone]

#209157

On 5/25/19 4:49 PM, Markos wrote:
> Hi,
> 
> 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 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. But that no user could 
> delete or write to the file books.db (only the program reading_room.tcl)
> 
> Please, how can I configure the system to do that?
> 
> How to define the permissions?
> 
> Thanks,
> 
> Markos

Some possibilities:

https://en.wikipedia.org/wiki/Setuid

https://en.wikipedia.org/wiki/Client%E2%80%93server_model

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller


David

[toc] | [prev] | [next] | [standalone]

#209158

On 2019-05-26 00:49, Markos wrote:
> Hi,
> 
> 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 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. But that no user could
> delete or write to the file books.db (only the program
> reading_room.tcl)
> 
> Please, how can I configure the system to do that?
> 
> How to define the permissions?

I'll have a go, sure I'll get pulled up if off.

read 4, write 2, execute 1  add these together for permissions
owner, group, anybody

I never did anything on a PC with other people having access so I never 
made a file only executable by anybody but I don't see why not.
As you wrote reading_room.tcl presume that belongs to you.
I don't know anything about tcl as yet but assume it's executable as it 
is and does something.
You may have a group librarians that want to have read/write access to 
reading_room.tcl
Assume you have backups of the files.
guess books.db wants to be 644
"su -"
"chmod 644 books.db"
  or if the librarians want write access to it.
"chown you.librarians books.db"
"chmod 664 books.db"

"chown you.librarians reading_room.tcl"
"chmod 771 reading_room.tcl"

mick


-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#209159

On 5/25/19 8:12 PM, mick crane wrote:
> On 2019-05-26 00:49, Markos wrote:
>> Hi,
>>
>> 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 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. But that no user could
>> delete or write to the file books.db (only the program
>> reading_room.tcl)
>>
>> Please, how can I configure the system to do that?
>>
>> How to define the permissions?
> 
> I'll have a go, sure I'll get pulled up if off.
> 
> read 4, write 2, execute 1  add these together for permissions
> owner, group, anybody
> 
> I never did anything on a PC with other people having access so I never 
> made a file only executable by anybody but I don't see why not.
> As you wrote reading_room.tcl presume that belongs to you.
> I don't know anything about tcl as yet but assume it's executable as it 
> is and does something.
> You may have a group librarians that want to have read/write access to 
> reading_room.tcl
> Assume you have backups of the files.
> guess books.db wants to be 644
> "su -"
> "chmod 644 books.db"
>   or if the librarians want write access to it.
> "chown you.librarians books.db"
> "chmod 664 books.db"
> 
> "chown you.librarians reading_room.tcl"
> "chmod 771 reading_room.tcl"
> 
> mick


I don't believe there is a solution using just read, write, and mode 
bits and group membership.  (Perhaps, there is a solution if you also 
use access control lists?)


Suppose I have a Perl script "shared-program.pl" (sorry, I don't know 
TCL) that reads a line from the terminal, lower cases the line, and then 
writes the line to the terminal.  If the line contains the word "write', 
the line is also written to a data file "shared-program.dat":

2019-05-25 20:31:43 dpchrist@tinkywinky ~
$ ll sandbox/perl5/shared-program.pl
-rwxr-xr-x 1 dpchrist dpchrist 267 2019-05-25 20:31:35 
sandbox/perl5/shared-program.pl*

2019-05-25 20:31:49 dpchrist@tinkywinky ~
$ cat sandbox/perl5/shared-program.pl
#!/usr/bin/env perl
use strict;
use warnings;
use FindBin	qw( $Bin );
use File::Slurp;
use constant DATAFILE => "$Bin/shared-program.dat";
print "$0 >";
my $line = <>;
$line = lc $line;
write_file(DATAFILE, {append => 1}, $line)
     if $line =~ /write/;
print $line;


If I run the program as the owner, it works as expected:

2019-05-25 20:34:01 dpchrist@tinkywinky ~
$ sandbox/perl5/shared-program.pl
sandbox/perl5/shared-program.pl >Hi, Dave!
hi, dave!

2019-05-25 20:34:15 dpchrist@tinkywinky ~
$ sandbox/perl5/shared-program.pl
sandbox/perl5/shared-program.pl >write Bye, Dave!
write bye, dave!

2019-05-25 20:35:09 dpchrist@tinkywinky ~
$ ll sandbox/perl5/shared-program.dat
-rw-r--r-- 1 dpchrist dpchrist 17 2019-05-25 20:35:09 
sandbox/perl5/shared-program.dat

2019-05-25 20:35:22 dpchrist@tinkywinky ~
$ cat sandbox/perl5/shared-program.dat
write bye, dave!


The mode of 755 on the script allows other group members and all other 
users to run the script:

tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
/home/dpchrist/sandbox/perl5/shared-program.pl >Hello, Tinky Winky!
hello, tinky winky!


But, if I clear the world read bit on the script:

2019-05-25 20:35:24 dpchrist@tinkywinky ~
$ chmod o-r sandbox/perl5/shared-program.pl

2019-05-25 20:38:08 dpchrist@tinkywinky ~
$ ll sandbox/perl5/shared-program.pl
-rwxr-x--x 1 dpchrist dpchrist 267 2019-05-25 20:31:35 
sandbox/perl5/shared-program.pl*


Other users are not able to run the script because the Perl interpreter 
cannot read the script:

tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
Can't open perl script "/home/dpchrist/sandbox/perl5/shared-program.pl": 
Permission denied


(It might be possible for other users to run binary programs with just 
the world execute bit set?)


So, the world mode needs to be read+execute for other users to run 
scripts they do not own:

2019-05-25 20:59:32 dpchrist@tinkywinky ~
$ chmod o=rx sandbox/perl5/shared-program.pl

2019-05-25 21:05:53 dpchrist@tinkywinky ~
$ ll sandbox/perl5/shared-program.pl
-rwxr-xr-x 1 dpchrist dpchrist 267 2019-05-25 20:31:35 
sandbox/perl5/shared-program.pl*

tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
/home/dpchrist/sandbox/perl5/shared-program.pl >Blah Blah Blab
blah blah blab


Focusing on the data file, let's add the other user to the file's group:

2019-05-25 20:49:08 root@tinkywinky ~
# usermod -a -G dpchrist tinkywinky

2019-05-25 20:50:33 root@tinkywinky ~
# grep dpchrist /etc/group | grep tinkywinky
dpchrist:x:13250:tinkywinky


Log out and log in again as the other user to obtain the new group 
membership.


Enable the group write bit on the data file:

2019-05-25 21:09:45 dpchrist@tinkywinky ~
$ chmod g+w sandbox/perl5/shared-program.dat

2019-05-25 21:11:50 dpchrist@tinkywinky ~
$ ll sandbox/perl5/shared-program.dat
-rw-rw-r-- 1 dpchrist dpchrist 17 2019-05-25 20:35:09 
sandbox/perl5/shared-program.dat


Now the script can write to the data file when the script is run by 
other users in the same group:

tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
/home/dpchrist/sandbox/perl5/shared-program.pl >write Yada Yada
write yada yada

tinkywinky@tinkywinky:~$ cat /home/dpchrist/sandbox/perl5/shared-program.dat
write bye, dave!
write yada yada


But, those other user can also trash the data file directly:

tinkywinky@tinkywinky:~$ echo "Muahahahahaha"  > 
/home/dpchrist/sandbox/perl5/shared-program.dat

tinkywinky@tinkywinky:~$ cat /home/dpchrist/sandbox/perl5/shared-program.dat
Muahahahahaha


This is situation the OP wants to avoid.


David

[toc] | [prev] | [next] | [standalone]

#209161

On 2019-05-26 05:32, David Christensen wrote:
> On 5/25/19 8:12 PM, mick crane wrote:
>> On 2019-05-26 00:49, Markos wrote:
>>> Hi,
>>> 
>>> 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 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. But that no user could
>>> delete or write to the file books.db (only the program
>>> reading_room.tcl)
>>> 
>>> Please, how can I configure the system to do that?
>>> 
>>> How to define the permissions?
>> 
>> I'll have a go, sure I'll get pulled up if off.
>> 
>> read 4, write 2, execute 1?? add these together for permissions
>> owner, group, anybody
>> 
>> I never did anything on a PC with other people having access so I 
>> never made a file only executable by anybody but I don't see why not.
>> As you wrote reading_room.tcl presume that belongs to you.
>> I don't know anything about tcl as yet but assume it's executable as 
>> it is and does something.
>> You may have a group librarians that want to have read/write access to 
>> reading_room.tcl
>> Assume you have backups of the files.
>> guess books.db wants to be 644
>> "su -"
>> "chmod 644 books.db"
>>  ??or if the librarians want write access to it.
>> "chown you.librarians books.db"
>> "chmod 664 books.db"
>> 
>> "chown you.librarians reading_room.tcl"
>> "chmod 771 reading_room.tcl"
>> 
>> mick
> 
> 
> I don't believe there is a solution using just read, write, and mode
> bits and group membership.  (Perhaps, there is a solution if you also
> use access control lists?)
> 
> 
> Suppose I have a Perl script "shared-program.pl" (sorry, I don't know
> TCL) that reads a line from the terminal, lower cases the line, and
> then writes the line to the terminal.  If the line contains the word
> "write', the line is also written to a data file "shared-program.dat":
> 
> 2019-05-25 20:31:43 dpchrist@tinkywinky ~
> $ ll sandbox/perl5/shared-program.pl
> -rwxr-xr-x 1 dpchrist dpchrist 267 2019-05-25 20:31:35
> sandbox/perl5/shared-program.pl*
> 
> 2019-05-25 20:31:49 dpchrist@tinkywinky ~
> $ cat sandbox/perl5/shared-program.pl
> #!/usr/bin/env perl
> use strict;
> use warnings;
> use FindBin	qw( $Bin );
> use File::Slurp;
> use constant DATAFILE => "$Bin/shared-program.dat";
> print "$0 >";
> my $line = <>;
> $line = lc $line;
> write_file(DATAFILE, {append => 1}, $line)
>     if $line =~ /write/;
> print $line;
> 
> 
> If I run the program as the owner, it works as expected:
> 
> 2019-05-25 20:34:01 dpchrist@tinkywinky ~
> $ sandbox/perl5/shared-program.pl
> sandbox/perl5/shared-program.pl >Hi, Dave!
> hi, dave!
> 
> 2019-05-25 20:34:15 dpchrist@tinkywinky ~
> $ sandbox/perl5/shared-program.pl
> sandbox/perl5/shared-program.pl >write Bye, Dave!
> write bye, dave!
> 
> 2019-05-25 20:35:09 dpchrist@tinkywinky ~
> $ ll sandbox/perl5/shared-program.dat
> -rw-r--r-- 1 dpchrist dpchrist 17 2019-05-25 20:35:09
> sandbox/perl5/shared-program.dat
> 
> 2019-05-25 20:35:22 dpchrist@tinkywinky ~
> $ cat sandbox/perl5/shared-program.dat
> write bye, dave!
> 
> 
> The mode of 755 on the script allows other group members and all other
> users to run the script:
> 
> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
> /home/dpchrist/sandbox/perl5/shared-program.pl >Hello, Tinky Winky!
> hello, tinky winky!
> 
> 
> But, if I clear the world read bit on the script:
> 
> 2019-05-25 20:35:24 dpchrist@tinkywinky ~
> $ chmod o-r sandbox/perl5/shared-program.pl
> 
> 2019-05-25 20:38:08 dpchrist@tinkywinky ~
> $ ll sandbox/perl5/shared-program.pl
> -rwxr-x--x 1 dpchrist dpchrist 267 2019-05-25 20:31:35
> sandbox/perl5/shared-program.pl*
> 
> 
> Other users are not able to run the script because the Perl
> interpreter cannot read the script:
> 
> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
> Can't open perl script
> "/home/dpchrist/sandbox/perl5/shared-program.pl": Permission denied
> 
> 
> (It might be possible for other users to run binary programs with just
> the world execute bit set?)
> 
> 
> So, the world mode needs to be read+execute for other users to run
> scripts they do not own:
> 
> 2019-05-25 20:59:32 dpchrist@tinkywinky ~
> $ chmod o=rx sandbox/perl5/shared-program.pl
> 
> 2019-05-25 21:05:53 dpchrist@tinkywinky ~
> $ ll sandbox/perl5/shared-program.pl
> -rwxr-xr-x 1 dpchrist dpchrist 267 2019-05-25 20:31:35
> sandbox/perl5/shared-program.pl*
> 
> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
> /home/dpchrist/sandbox/perl5/shared-program.pl >Blah Blah Blab
> blah blah blab
> 
> 
> Focusing on the data file, let's add the other user to the file's 
> group:
> 
> 2019-05-25 20:49:08 root@tinkywinky ~
> # usermod -a -G dpchrist tinkywinky
> 
> 2019-05-25 20:50:33 root@tinkywinky ~
> # grep dpchrist /etc/group | grep tinkywinky
> dpchrist:x:13250:tinkywinky
> 
> 
> Log out and log in again as the other user to obtain the new group 
> membership.
> 
> 
> Enable the group write bit on the data file:
> 
> 2019-05-25 21:09:45 dpchrist@tinkywinky ~
> $ chmod g+w sandbox/perl5/shared-program.dat
> 
> 2019-05-25 21:11:50 dpchrist@tinkywinky ~
> $ ll sandbox/perl5/shared-program.dat
> -rw-rw-r-- 1 dpchrist dpchrist 17 2019-05-25 20:35:09
> sandbox/perl5/shared-program.dat
> 
> 
> Now the script can write to the data file when the script is run by
> other users in the same group:
> 
> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
> /home/dpchrist/sandbox/perl5/shared-program.pl >write Yada Yada
> write yada yada
> 
> tinkywinky@tinkywinky:~$ cat 
> /home/dpchrist/sandbox/perl5/shared-program.dat
> write bye, dave!
> write yada yada
> 
> 
> But, those other user can also trash the data file directly:
> 
> tinkywinky@tinkywinky:~$ echo "Muahahahahaha"  >
> /home/dpchrist/sandbox/perl5/shared-program.dat
> 
> tinkywinky@tinkywinky:~$ cat 
> /home/dpchrist/sandbox/perl5/shared-program.dat
> Muahahahahaha
> 
> 
> This is situation the OP wants to avoid.
> 
> 
> David

well that would be people in the supposedly trustworthy librarians 
group.
I did wonder if executable file would have to world readable as well as 
executable but possibly there might be passwords in it, however that 
works.
mick@slinky:~$ ls -la test1
---x--x--x 1 mick mick 25 May 26 05:56 test1
mick@slinky:~$ ./test1
/bin/bash: ./test1: Permission denied

seems tcl files can be made self contained executable so that might get 
over it being readable.

mick


-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#209781

[Multipart message — attachments visible in raw view] — view raw

Many thanks to Mick, David and Joe,

To guarantee "some" protection to the file 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.

And can't delete the files (.tcl or .db)

Trying to protect against Murphy, but not Machiavelli.

Thank you,
Markos


Em 26-05-2019 02:06, mick crane escreveu:
> On 2019-05-26 05:32, David Christensen wrote:
>> On 5/25/19 8:12 PM, mick crane wrote:
>>> On 2019-05-26 00:49, Markos wrote:
>>>> Hi,
>>>>
>>>> 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 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. But that no user could
>>>> delete or write to the file books.db (only the program
>>>> reading_room.tcl)
>>>>
>>>> Please, how can I configure the system to do that?
>>>>
>>>> How to define the permissions?
>>>
>>> I'll have a go, sure I'll get pulled up if off.
>>>
>>> read 4, write 2, execute 1?? add these together for permissions
>>> owner, group, anybody
>>>
>>> I never did anything on a PC with other people having access so I 
>>> never made a file only executable by anybody but I don't see why not.
>>> As you wrote reading_room.tcl presume that belongs to you.
>>> I don't know anything about tcl as yet but assume it's executable as 
>>> it is and does something.
>>> You may have a group librarians that want to have read/write access 
>>> to reading_room.tcl
>>> Assume you have backups of the files.
>>> guess books.db wants to be 644
>>> "su -"
>>> "chmod 644 books.db"
>>>  ??or if the librarians want write access to it.
>>> "chown you.librarians books.db"
>>> "chmod 664 books.db"
>>>
>>> "chown you.librarians reading_room.tcl"
>>> "chmod 771 reading_room.tcl"
>>>
>>> mick
>>
>>
>> I don't believe there is a solution using just read, write, and mode
>> bits and group membership.  (Perhaps, there is a solution if you also
>> use access control lists?)
>>
>>
>> Suppose I have a Perl script "shared-program.pl" (sorry, I don't know
>> TCL) that reads a line from the terminal, lower cases the line, and
>> then writes the line to the terminal.  If the line contains the word
>> "write', the line is also written to a data file "shared-program.dat":
>>
>> 2019-05-25 20:31:43 dpchrist@tinkywinky ~
>> $ ll sandbox/perl5/shared-program.pl
>> -rwxr-xr-x 1 dpchrist dpchrist 267 2019-05-25 20:31:35
>> sandbox/perl5/shared-program.pl*
>>
>> 2019-05-25 20:31:49 dpchrist@tinkywinky ~
>> $ cat sandbox/perl5/shared-program.pl
>> #!/usr/bin/env perl
>> use strict;
>> use warnings;
>> use FindBin    qw( $Bin );
>> use File::Slurp;
>> use constant DATAFILE => "$Bin/shared-program.dat";
>> print "$0 >";
>> my $line = <>;
>> $line = lc $line;
>> write_file(DATAFILE, {append => 1}, $line)
>>     if $line =~ /write/;
>> print $line;
>>
>>
>> If I run the program as the owner, it works as expected:
>>
>> 2019-05-25 20:34:01 dpchrist@tinkywinky ~
>> $ sandbox/perl5/shared-program.pl
>> sandbox/perl5/shared-program.pl >Hi, Dave!
>> hi, dave!
>>
>> 2019-05-25 20:34:15 dpchrist@tinkywinky ~
>> $ sandbox/perl5/shared-program.pl
>> sandbox/perl5/shared-program.pl >write Bye, Dave!
>> write bye, dave!
>>
>> 2019-05-25 20:35:09 dpchrist@tinkywinky ~
>> $ ll sandbox/perl5/shared-program.dat
>> -rw-r--r-- 1 dpchrist dpchrist 17 2019-05-25 20:35:09
>> sandbox/perl5/shared-program.dat
>>
>> 2019-05-25 20:35:22 dpchrist@tinkywinky ~
>> $ cat sandbox/perl5/shared-program.dat
>> write bye, dave!
>>
>>
>> The mode of 755 on the script allows other group members and all other
>> users to run the script:
>>
>> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
>> /home/dpchrist/sandbox/perl5/shared-program.pl >Hello, Tinky Winky!
>> hello, tinky winky!
>>
>>
>> But, if I clear the world read bit on the script:
>>
>> 2019-05-25 20:35:24 dpchrist@tinkywinky ~
>> $ chmod o-r sandbox/perl5/shared-program.pl
>>
>> 2019-05-25 20:38:08 dpchrist@tinkywinky ~
>> $ ll sandbox/perl5/shared-program.pl
>> -rwxr-x--x 1 dpchrist dpchrist 267 2019-05-25 20:31:35
>> sandbox/perl5/shared-program.pl*
>>
>>
>> Other users are not able to run the script because the Perl
>> interpreter cannot read the script:
>>
>> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
>> Can't open perl script
>> "/home/dpchrist/sandbox/perl5/shared-program.pl": Permission denied
>>
>>
>> (It might be possible for other users to run binary programs with just
>> the world execute bit set?)
>>
>>
>> So, the world mode needs to be read+execute for other users to run
>> scripts they do not own:
>>
>> 2019-05-25 20:59:32 dpchrist@tinkywinky ~
>> $ chmod o=rx sandbox/perl5/shared-program.pl
>>
>> 2019-05-25 21:05:53 dpchrist@tinkywinky ~
>> $ ll sandbox/perl5/shared-program.pl
>> -rwxr-xr-x 1 dpchrist dpchrist 267 2019-05-25 20:31:35
>> sandbox/perl5/shared-program.pl*
>>
>> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
>> /home/dpchrist/sandbox/perl5/shared-program.pl >Blah Blah Blab
>> blah blah blab
>>
>>
>> Focusing on the data file, let's add the other user to the file's group:
>>
>> 2019-05-25 20:49:08 root@tinkywinky ~
>> # usermod -a -G dpchrist tinkywinky
>>
>> 2019-05-25 20:50:33 root@tinkywinky ~
>> # grep dpchrist /etc/group | grep tinkywinky
>> dpchrist:x:13250:tinkywinky
>>
>>
>> Log out and log in again as the other user to obtain the new group 
>> membership.
>>
>>
>> Enable the group write bit on the data file:
>>
>> 2019-05-25 21:09:45 dpchrist@tinkywinky ~
>> $ chmod g+w sandbox/perl5/shared-program.dat
>>
>> 2019-05-25 21:11:50 dpchrist@tinkywinky ~
>> $ ll sandbox/perl5/shared-program.dat
>> -rw-rw-r-- 1 dpchrist dpchrist 17 2019-05-25 20:35:09
>> sandbox/perl5/shared-program.dat
>>
>>
>> Now the script can write to the data file when the script is run by
>> other users in the same group:
>>
>> tinkywinky@tinkywinky:~$ /home/dpchrist/sandbox/perl5/shared-program.pl
>> /home/dpchrist/sandbox/perl5/shared-program.pl >write Yada Yada
>> write yada yada
>>
>> tinkywinky@tinkywinky:~$ cat 
>> /home/dpchrist/sandbox/perl5/shared-program.dat
>> write bye, dave!
>> write yada yada
>>
>>
>> But, those other user can also trash the data file directly:
>>
>> tinkywinky@tinkywinky:~$ echo "Muahahahahaha"  >
>> /home/dpchrist/sandbox/perl5/shared-program.dat
>>
>> tinkywinky@tinkywinky:~$ cat 
>> /home/dpchrist/sandbox/perl5/shared-program.dat
>> Muahahahahaha
>>
>>
>> This is situation the OP wants to avoid.
>>
>>
>> David
>
> well that would be people in the supposedly trustworthy librarians group.
> I did wonder if executable file would have to world readable as well 
> as executable but possibly there might be passwords in it, however 
> that works.
> mick@slinky:~$ ls -la test1
> ---x--x--x 1 mick mick 25 May 26 05:56 test1
> mick@slinky:~$ ./test1
> /bin/bash: ./test1: Permission denied
>
> seems tcl files can be made self contained executable so that might 
> get over it being readable.
>
> mick
>
>

[toc] | [prev] | [next] | [standalone]

#209782

On 2019-06-09 22:32, Markos wrote:

> reading_room.db rw-r--rw- (owner markos)
why give world write access to the database ?
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#209785

	Hi.

On Sun, Jun 09, 2019 at 06:32:42PM -0300, Markos wrote:
> Many thanks to Mick, David and Joe,
> 
> To guarantee "some" protection to the file 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.

Try it someday.

cd /tmp
echo foo 1.db
chmod 646 1.db
echo bar | sudo -u nobody tee /tmp/1.db >/dev/null
cat 1.db

Sticky bit combined with 'w' allows user to overwrite (or append) the
file.

> And can't delete the files (.tcl or .db)

That's true, and since most editors try to use "create temporary file
and move it along the original" - you mistook it for "other users cannot
edit the file".

Reco

[toc] | [prev] | [next] | [standalone]

#209789

On 6/10/2019 7:56 AM, Reco wrote:
> 	Hi.
>
> On Sun, Jun 09, 2019 at 06:32:42PM -0300, Markos wrote:
>> Many thanks to Mick, David and Joe,
>>
>> To guarantee "some" protection to the file containing the database I decided to use the following strategy:
>>
>> I created, as root, the directory /home/reading_room
>>

Is '/home/reading_room' a defined user on the host?
If no, choosing a home directory with an non-existing user might not be
the best idea.


https://www.debian.org/releases/stable/i386/apcs02.html.en

--
John Doe

[toc] | [prev] | [next] | [standalone]

#209813

On 6/9/19 2:32 PM, Markos wrote:
> Many thanks to Mick, David and Joe,
> 
> To guarantee "some" protection to the file 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.
> 
> And can't delete the files (.tcl or .db)
> 
> Trying to protect against Murphy, but not Machiavelli.
> 
> Thank you,
> Markos

I created a test setup similar to your solution:

2019-06-10 08:23:27 dpchrist@tinkywinky ~
$ cat /etc/debian_version ; uname -a
9.9
Linux tinkywinky 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 
(2019-05-13) x86_64 GNU/Linux

2019-06-10 08:14:52 dpchrist@tinkywinky ~
$ mkdir foo

2019-06-10 08:16:33 dpchrist@tinkywinky ~
$ chmod +t foo

2019-06-10 08:29:54 dpchrist@tinkywinky ~
$ echo 'echo "hello" >> /home/dpchrist/foo/hello.txt' > foo/hello.sh

2019-06-10 08:30:08 dpchrist@tinkywinky ~
$ chmod 0745 foo/hello.sh

2019-06-10 08:30:14 dpchrist@tinkywinky ~
$ echo 'initial contents' > foo/hello.txt

2019-06-10 08:30:40 dpchrist@tinkywinky ~
$ chmod 0646 foo/hello.txt

2019-06-10 08:30:53 dpchrist@tinkywinky ~
$ ls -l foo/hello.*
-rwxr--r-x 1 dpchrist dpchrist 45 Jun 10 08:30 foo/hello.sh
-rw-r--rw- 1 dpchrist dpchrist 17 Jun 10 08:30 foo/hello.txt

2019-06-10 08:31:29 dpchrist@tinkywinky ~
$ cat foo/hello.sh
echo "hello" >> /home/dpchrist/foo/hello.txt

2019-06-10 08:31:34 dpchrist@tinkywinky ~
$ cat foo/hello.txt
initial contents


If I test it as another user:

tinkywinky@tinkywinky:~$ ls -la /home/dpchrist/foo
total 8
drwxr-xr-t 1 dpchrist dpchrist   34 Jun 10 08:29 .
drwxr-xr-x 1 dpchrist dpchrist 1694 Jun 10 08:20 ..
-rwxr--r-x 1 dpchrist dpchrist   45 Jun 10 08:30 hello.sh
-rw-r--rw- 1 dpchrist dpchrist   23 Jun 10 08:39 hello.txt

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.sh
echo "hello" >> /home/dpchrist/foo/hello.txt

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.txt
initial contents

So, other users:

- Can see the script file system entry.

- Can see the data file file system entry.

- Can see the contents of the script (!).

- Can see the contents of the data file (!).


Continue testing:

tinkywinky@tinkywinky:~$ /bin/sh /home/dpchrist/foo/hello.sh

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.txt
initial contents
hello

So:

- Other users can run the script.

- The script can write to the data file.


Continue testing:

tinkywinky@tinkywinky:~$ rm -rf /home/dpchrist/foo
rm: cannot remove '/home/dpchrist/foo/hello.sh': Permission denied
rm: cannot remove '/home/dpchrist/foo/hello.txt': Permission denied

So, other users:

- Cannot delete the script.

- Cannot delete the data file.


Continue testing:

tinkywinky@tinkywinky:~$ echo "blah" > /home/dpchrist/foo/hello.sh
-bash: /home/dpchrist/foo/hello.sh: Permission denied

tinkywinky@tinkywinky:~$ echo "blah" > /home/dpchrist/foo/hello.txt

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.txt
blah

So, other users:

- Cannot overwrite the script.

- Can overwrite the data file (!).


Continue testing:

tinkywinky@tinkywinky:~$ vi /home/dpchrist/foo/hello.sh
echo "pwn3d" >> /home/dpchrist/foo/hello.txt
:w
E45: 'readonly' option is set (add ! to override)
:w!
"/home/dpchrist/foo/hello.sh" E212: Can't open file for writing
Press ENTER or type command to continue
:q!

tinkywinky@tinkywinky:~$ vi /home/dpchrist/foo/hello.txt
pwn3d
:w
"/home/dpchrist/foo/hello.txt" 1 line, 6 characters written
:q

So, other users:

- Cannot edit the script.

- Can edit the data file (!).


You have found an interesting combination of mode bits and multi-user 
behavior.  I can see how that could work in a "friendly" environment, 
where you are protecting against mistakes rather than protecting against 
attacks.


You will want to back up the data file frequently.


It has been many years since I played with the special mode bits.  This 
article is a decent refresher:

https://linuxconfig.org/how-to-use-special-permissions-the-setuid-setgid-and-sticky-bits


I found another article that describes how to wrap a script with a C 
program, so that the set UID and set GID bits will work.

https://engineering.purdue.edu/ECN/Support/KB/Docs/HowToSUIDSGIDscripts


If you created a restricted user account just for the app and data, 
created an executable wrapper, and adjusted the mode bits, I believe you 
could prevent users from seeing the contents of the script, seeing the 
contents of the database, overwriting the database, and editing the 
database.


David

[toc] | [prev] | [next] | [standalone]

#209164

On Sat, 25 May 2019 20:49:31 -0300
Markos <markos@c2o.pro.br> wrote:

> Hi,
> 
> 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 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. But that no user could 
> delete or write to the file books.db (only the program
> reading_room.tcl)
> 
> Please, how can I configure the system to do that?
> 
> How to define the permissions?
> 

I hate to say this, but this is why database management applications
have their own self-contained authentication and permissions systems.
Filesystem controls, even with granular ACL add-ons, are not generally
adequate for database work. DBMS authentication allows access control
down to individual fields and distinguishes between database
management actions and simple data access.

This may be the time to learn about MySQL/mariadb. No, it's not a
resource hog like SQL Server, it will run happily on a small computer.
I used to run it with fairly decent speed on an Atom-based netbook,
and I had about twenty databases on a 256MB RAM desktop that I used to
use as a home server.

The other point is that if your reading room expands to multiple
computers, sqlite isn't an ideal solution for a shared database. It has
the same drawback as MS Access files in that a network glitch can break
the file. Any SQL server is designed for network use and will handle
connection problems robustly.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#209783

Joe wrote: 
> 
> This may be the time to learn about MySQL/mariadb. No, it's not a
> resource hog like SQL Server, it will run happily on a small computer.
> I used to run it with fairly decent speed on an Atom-based netbook,
> and I had about twenty databases on a 256MB RAM desktop that I used to
> use as a home server.

I'll just point out that in 2000, a midsized database server might
have four cpu cores running at 1GHz each, 512MB of RAM and four
disks capable of a total of 400 operations per second and a
total read bandwidth of perhaps 500MB/s.

We have incredibly cheap resources available now, and running
MariaDB or Postgresql or another "major" database is within
reach of basically any desktop computer of the last five years.

-dsr- 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web