Bug 133818 - bacula-server-2.4.2: make_sqlite_tables sets wrong permmisions to db file
Summary: bacula-server-2.4.2: make_sqlite_tables sets wrong permmisions to db file
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Wesley Shields
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-17 17:40 UTC by Kostas Voulgaris
Modified: 2009-08-14 21:03 UTC (History)
0 users

See Also:


Attachments
bacula-server-devel.diff (996 bytes, patch)
2009-04-23 23:56 UTC, Wesley Shields
no flags Details | Diff
bacula-server.diff (1019 bytes, patch)
2009-04-23 23:56 UTC, Wesley Shields
no flags Details | Diff
bacula.diff (2.66 KB, patch)
2009-07-28 20:09 UTC, Wesley Shields
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kostas Voulgaris 2009-04-17 17:40:03 UTC
The script /usr/local/share/bacula/make_sqlite_tables that creates the sqlite database file in /var/db/bacula/bacula.db (default path) should set the file's owner to bacula and group to bacula instead of root:bacula. If not the bacula director (runs as user bacula) cannot write to the database. The problem[1] and the solution[2] is described in bacula-users mailing list and exists since 2007 but noone has reported it yet.

The problem is noticed when trying to run any configured backup job. You get errors when trying to insert data in database like this one: 

14-Apr 18:06 srv-dir JobId 0: Fatal error: sql_create.c:524 sql_create.c:524 insert INSERT INTO Client (Name,Uname,AutoPrune,FileRetention,JobRetention) VALUES ('spooky-fd','',1,2592000,15552000) failed:
attempt to write a readonly database
14-Apr 18:06 srv-dir JobId 0: sql_create.c:524 INSERT INTO Client (Name,Uname,AutoPrune,FileRetention,JobRetention) VALUES ('spooky-fd','',1,2592000,15552000)
14-Apr 18:06 srv-dir JobId 0: Error: sql_create.c:526 Create DB Client record INSERT INTO Client (Name,Uname,AutoPrune,FileRetention,JobRetention) VALUES ('spooky-fd','',1,2592000,15552000) failed. ERR=attempt to write a readonly database
14-Apr 18:06 srv-dir JobId 0: Fatal error: Could not create Client record. ERR=sql_create.c:526 Create DB Client record INSERT INTO Client (Name,Uname,AutoPrune,FileRetention,JobRetention) VALUES ('spooky-fd','',1,2592000,15552000) failed. ERR=attempt to write a readonly database

----

[1] http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg21700.html
[2] http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg21725.html

Fix: 

The command:

  chown bacula:bacula ${db_name}.db

should be appended at the make_sqlite_tables script.
How-To-Repeat: i) install bacula-server-2.4.2
ii) run /usr/local/share/bacula/make_sqlite_tables to initialize the database
iii) run any backup job
Comment 1 Wesley Shields freebsd_committer 2009-04-17 19:08:51 UTC
Responsible Changed
From-To: freebsd-ports-bugs->wxs

I'll take it.
Comment 2 Dan Langille 2009-04-19 03:52:14 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

workaround:

Step ii) should be run as the bacula user to avoid this problem.

I just tried to test this, but failed to get the port to compile (2.4.2)
with SQLite.  It also appears the port always selects SQLite3 and cannot
be made to use SQLite2.

My time until late May is committed to BSDCan and PGCon.  If someone
else wishes to look at this: the Makefile already assumes bacula-dir
will run as the bacula user.  Look for "--with-dir-user=bacula".  So
patching the file seems logical to me.

- --
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknqkd4ACgkQCgsXFM/7nTxDSQCbBpbhLh4TP+QxWw8R5gVpMGgi
o+MAoIoD2yfFxJOmjsZ55+5yuckjxOa7
=Q/71
-----END PGP SIGNATURE-----
Comment 3 Wesley Shields freebsd_committer 2009-04-21 15:23:46 UTC
State Changed
From-To: open->closed

Maintainer has stated a correct fix for this problem is to run 
make_sqlite_tables as the bacula user.
Comment 4 Kostas Voulgaris 2009-04-21 15:52:30 UTC
User bacula, when created after package installation, has login
shell /sbin/nologin. Please change it in order to be able to login and
run the database initialization scripts.
Comment 5 Wesley Shields freebsd_committer 2009-04-21 16:31:35 UTC
State Changed
From-To: closed->open

Re-open as submitter has a valid point.  The shell should be changed so that the account can be used to initalize the database.  I'll work with Dan to get this fixed.
Comment 6 Wesley Shields freebsd_committer 2009-04-23 23:56:13 UTC
How do the attached patches look?  They change the login shell to be
/bin/sh instead of /sbin/nologin.

-- WXS
Comment 7 Dan Langille 2009-04-25 18:36:54 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wesley Shields wrote:
> How do the attached patches look?  They change the login shell to be
> /bin/sh instead of /sbin/nologin.

Am I correct: You don't have to login as bacula to run a command as
bacula. Can su or sudo can handle this?

see http://www.freebsddiary.org/phorum/read.php?f=4&i=315&t=315

Offhand, I understood the poing of /sbin/nologin was to prevent people
from logging in as the daemon.

- --
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknzSjYACgkQCgsXFM/7nTxt+gCfUwCLD4a1LuO5EAZ7lknNHjDO
7M8AoMAddV9BZXZ9sxGU/ylA4nKuGWxO
=M3YS
-----END PGP SIGNATURE-----
Comment 8 Wesley Shields freebsd_committer 2009-07-24 21:03:32 UTC
Sorry for the delay, this must have got lost on my end at some point.

On Sat, Apr 25, 2009 at 05:40:02PM +0000, Dan Langille wrote:
>  Wesley Shields wrote:
>  > How do the attached patches look?  They change the login shell to be
>  > /bin/sh instead of /sbin/nologin.
>  
>  Am I correct: You don't have to login as bacula to run a command as
>  bacula. Can su or sudo can handle this?

Sudo can handle it, su can not as far as I know.

Since not everybody uses sudo I think we should change the shell so that
people can execute the step with the correct permissions.

>  Offhand, I understood the poing of /sbin/nologin was to prevent people
>  from logging in as the daemon.

Yes, but in some cases it may be useful to become the same user as the
daemon - I'm specifically thinking about this case. Postgres is an
example of this:

pgsql:*:70:70:PostgreSQL Daemon:/usr/local/pgsql:/bin/sh

I've occasionally had the need to become the pgsql user to perform some
database tasks.

-- WXS
Comment 9 Wesley Shields freebsd_committer 2009-07-24 21:18:37 UTC
State Changed
From-To: open->feedback

Pending maintainer feedback.
Comment 10 Dan Langille 2009-07-26 02:10:43 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wesley Shields wrote:
> Sorry for the delay, this must have got lost on my end at some point.
> 
> On Sat, Apr 25, 2009 at 05:40:02PM +0000, Dan Langille wrote:
>>  Wesley Shields wrote:
>>  > How do the attached patches look?  They change the login shell to be
>>  > /bin/sh instead of /sbin/nologin.
>>  
>>  Am I correct: You don't have to login as bacula to run a command as
>>  bacula. Can su or sudo can handle this?
> 
> Sudo can handle it, su can not as far as I know.

[root@laptop /usr/home/dan]# su -m bacula
laptop# id
uid=910(bacula) gid=910(bacula) groups=910(bacula),5(operator)
laptop#

That looks like bacula to me.

- --
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkprrRMACgkQCgsXFM/7nTxiRgCgtXs5ZWps8IcH/YcyUgBVPBzK
3q0AoP3h6UoHVq6N9vhVj6QB4PmNp+Ga
=9sjd
-----END PGP SIGNATURE-----
Comment 11 Wesley Shields freebsd_committer 2009-07-28 01:52:44 UTC
On Sat, Jul 25, 2009 at 09:10:43PM -0400, Dan Langille wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Wesley Shields wrote:
> > Sorry for the delay, this must have got lost on my end at some point.
> > 
> > On Sat, Apr 25, 2009 at 05:40:02PM +0000, Dan Langille wrote:
> >>  Wesley Shields wrote:
> >>  > How do the attached patches look?  They change the login shell to be
> >>  > /bin/sh instead of /sbin/nologin.
> >>  
> >>  Am I correct: You don't have to login as bacula to run a command as
> >>  bacula. Can su or sudo can handle this?
> > 
> > Sudo can handle it, su can not as far as I know.
> 
> [root@laptop /usr/home/dan]# su -m bacula
> laptop# id
> uid=910(bacula) gid=910(bacula) groups=910(bacula),5(operator)
> laptop#
> 
> That looks like bacula to me.

Doesn't that require a password to bet set on the bacula account? If I'm
reading the pkg-install script correctly it calls pw(8) with "-h -"
which locks the account.

-- WXS
Comment 12 Dan Langille 2009-07-28 02:27:02 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wesley Shields wrote:
> On Sat, Jul 25, 2009 at 09:10:43PM -0400, Dan Langille wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wesley Shields wrote:
>>> Sorry for the delay, this must have got lost on my end at some point.
>>>
>>> On Sat, Apr 25, 2009 at 05:40:02PM +0000, Dan Langille wrote:
>>>>  Wesley Shields wrote:
>>>>  > How do the attached patches look?  They change the login shell to be
>>>>  > /bin/sh instead of /sbin/nologin.
>>>>  
>>>>  Am I correct: You don't have to login as bacula to run a command as
>>>>  bacula. Can su or sudo can handle this?
>>> Sudo can handle it, su can not as far as I know.
>> [root@laptop /usr/home/dan]# su -m bacula
>> laptop# id
>> uid=910(bacula) gid=910(bacula) groups=910(bacula),5(operator)
>> laptop#
>>
>> That looks like bacula to me.
> 
> Doesn't that require a password to bet set on the bacula account? If I'm
> reading the pkg-install script correctly it calls pw(8) with "-h -"
> which locks the account.

The bacula account has no password:

[root@laptop ~]# grep bacula /etc/master.passwd
bacula:*:910:910::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin
[root@laptop ~]#

- --
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpuU+YACgkQCgsXFM/7nTx40ACfeM0psPZZohLXiZl5CV39qJ05
ah4AmwYjYJxLSlDuaz1yYkZ43RbQ44Ov
=xxqO
-----END PGP SIGNATURE-----
Comment 13 Wesley Shields freebsd_committer 2009-07-28 16:58:39 UTC
On Mon, Jul 27, 2009 at 09:27:02PM -0400, Dan Langille wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Wesley Shields wrote:
> > On Sat, Jul 25, 2009 at 09:10:43PM -0400, Dan Langille wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Wesley Shields wrote:
> >>> Sorry for the delay, this must have got lost on my end at some point.
> >>>
> >>> On Sat, Apr 25, 2009 at 05:40:02PM +0000, Dan Langille wrote:
> >>>>  Wesley Shields wrote:
> >>>>  > How do the attached patches look?  They change the login shell to be
> >>>>  > /bin/sh instead of /sbin/nologin.
> >>>>  
> >>>>  Am I correct: You don't have to login as bacula to run a command as
> >>>>  bacula. Can su or sudo can handle this?
> >>> Sudo can handle it, su can not as far as I know.
> >> [root@laptop /usr/home/dan]# su -m bacula
> >> laptop# id
> >> uid=910(bacula) gid=910(bacula) groups=910(bacula),5(operator)
> >> laptop#
> >>
> >> That looks like bacula to me.
> > 
> > Doesn't that require a password to bet set on the bacula account? If I'm
> > reading the pkg-install script correctly it calls pw(8) with "-h -"
> > which locks the account.
> 
> The bacula account has no password:
> 
> [root@laptop ~]# grep bacula /etc/master.passwd
> bacula:*:910:910::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin
> [root@laptop ~]#

I can't reproduce your conclusions.

I just installed sysutils/bacula-server and tried to use the line above
(su -m bacula) but the result was failure. Is it possible that there is
something else going on here?

-- WXS
Comment 14 Dan Langille 2009-07-28 18:54:27 UTC
I will try again. What was your failure message/error.

--  
Dan Langille
http://langille.org/


On Jul 28, 2009, at 11:58 AM, Wesley Shields <wxs@FreeBSD.org> wrote:

> On Mon, Jul 27, 2009 at 09:27:02PM -0400, Dan Langille wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wesley Shields wrote:
>>> On Sat, Jul 25, 2009 at 09:10:43PM -0400, Dan Langille wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Wesley Shields wrote:
>>>>> Sorry for the delay, this must have got lost on my end at some  
>>>>> point.
>>>>>
>>>>> On Sat, Apr 25, 2009 at 05:40:02PM +0000, Dan Langille wrote:
>>>>>> Wesley Shields wrote:
>>>>>>> How do the attached patches look?  They change the login shell  
>>>>>>> to be
>>>>>>> /bin/sh instead of /sbin/nologin.
>>>>>>
>>>>>> Am I correct: You don't have to login as bacula to run a  
>>>>>> command as
>>>>>> bacula. Can su or sudo can handle this?
>>>>> Sudo can handle it, su can not as far as I know.
>>>> [root@laptop /usr/home/dan]# su -m bacula
>>>> laptop# id
>>>> uid=910(bacula) gid=910(bacula) groups=910(bacula),5(operator)
>>>> laptop#
>>>>
>>>> That looks like bacula to me.
>>>
>>> Doesn't that require a password to bet set on the bacula account?  
>>> If I'm
>>> reading the pkg-install script correctly it calls pw(8) with "-h -"
>>> which locks the account.
>>
>> The bacula account has no password:
>>
>> [root@laptop ~]# grep bacula /etc/master.passwd
>> bacula:*:910:910::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin
>> [root@laptop ~]#
>
> I can't reproduce your conclusions.
>
> I just installed sysutils/bacula-server and tried to use the line  
> above
> (su -m bacula) but the result was failure. Is it possible that there  
> is
> something else going on here?
>
> -- WXS
Comment 15 Wesley Shields freebsd_committer 2009-07-28 19:01:36 UTC
On Tue, Jul 28, 2009 at 01:54:27PM -0400, Dan Langille wrote:
> I will try again. What was your failure message/error.

wxs@rst bacula-server % su -m bacula
Password:
su: Sorry

Doesn't help much. ;)

-- WXS
Comment 16 Dan Langille 2009-07-28 19:26:14 UTC
On Tue, July 28, 2009 2:01 pm, Wesley Shields wrote:
> On Tue, Jul 28, 2009 at 01:54:27PM -0400, Dan Langille wrote:
>> I will try again. What was your failure message/error.
>
> wxs@rst bacula-server % su -m bacula
> Password:
> su: Sorry
>
> Doesn't help much. ;)

It helps.

Now try that as root, not as wxs.

-- 
Dan Langille -- http://langille.org/
Comment 17 Wesley Shields freebsd_committer 2009-07-28 20:09:29 UTC
On Tue, Jul 28, 2009 at 02:26:14PM -0400, Dan Langille wrote:
> 
> On Tue, July 28, 2009 2:01 pm, Wesley Shields wrote:
> > On Tue, Jul 28, 2009 at 01:54:27PM -0400, Dan Langille wrote:
> >> I will try again. What was your failure message/error.
> >
> > wxs@rst bacula-server % su -m bacula
> > Password:
> > su: Sorry
> >
> > Doesn't help much. ;)
> 
> It helps.
> 
> Now try that as root, not as wxs.

Wow, it's been an insanely long month for me. Sorry for the noise.
Attached is a patch which does a couple of things:

- Remove whitespace in pkg-deinstall.server
- Uses %%PREFIX%% in files/pkg-message.client.in and
  files/pkg-message.server.in
- Document the need to run make_sqlite_tables as the bacula user

This patch has already been approved by Dan on IRC but miwi has another
patch to update the port to a new version. I'm attaching this patch for
reference so that they both can be committed at the same time.

-- WXS
Comment 18 Martin Wilke freebsd_committer 2009-07-28 20:11:04 UTC
Responsible Changed
From-To: wxs->miwi

take over to merge that in 3.0.2 update, oked by wesley
Comment 19 Martin Wilke freebsd_committer 2009-08-01 17:58:28 UTC
Responsible Changed
From-To: miwi->wxs

i lose the time with working on KDE 4.3 update, so i forward both to 
wesly.
Comment 20 Wesley Shields freebsd_committer 2009-08-14 21:03:23 UTC
State Changed
From-To: feedback->closed

Documentation on the proper fix has been added to the port.