Bug 11590 - Restrict the actions for the DB user
Summary: Restrict the actions for the DB user
Status: RESOLVED DUPLICATE of bug 20489
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 20071 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-01-21 14:42 UTC by Kyle M Hall
Modified: 2019-02-04 22:38 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 11590 - Librarian able to checkout item without setting branch first (1.55 KB, patch)
2014-01-21 14:45 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 11590: Restrict the actions for the DB user (14.05 KB, patch)
2015-07-13 08:21 UTC, Jonathan Druart
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 11590: Restrict the actions for the DB user (14.17 KB, patch)
2016-03-08 15:02 UTC, Blou
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2014-01-21 14:42:15 UTC
It is possible to begin circulating items to a patron without first setting your logged in branch!

To recreate:
1) From the "Search patrons" quick search, search for any patron
2) From this patron's details screen, click the "Check out" quick search and put in a valid patron cardnumber
3) You are now able to issue items to this patron without having set your logged in branch.

Video example: http://screencast.com/t/xvzRb8zYf
Comment 1 Kyle M Hall 2014-01-21 14:45:11 UTC Comment hidden (obsolete)
Comment 2 Robin Sheat 2014-01-21 22:07:51 UTC
The giant warning saying that you shouldn't do that indicates that you shouldn't do that. 

A better fix is is to make that warning a bit more compulsory, e.g. cutting off access to functions that aren't related to configuration/management if you're the database user.

Maybe also make the warning bigger and having blinking marqueed text so it doesn't get ignored.
Comment 3 Chris Cormack 2014-01-23 06:18:26 UTC
(In reply to Robin Sheat from comment #2)
> The giant warning saying that you shouldn't do that indicates that you
> shouldn't do that. 
> 
> A better fix is is to make that warning a bit more compulsory, e.g. cutting
> off access to functions that aren't related to configuration/management if
> you're the database user.
> 
> Maybe also make the warning bigger and having blinking marqueed text so it
> doesn't get ignored.

Yep, what Robin is saying is that the real problem here is that you are logged in not as a real user but the db user.

I agree that we should definitely not let the db user ever circulate. That would be a much better solution. Also, lots of other features should be blocked too.
Comment 4 Kyle M Hall 2014-02-24 16:39:05 UTC
At this point I wonder why we still allow logins as the DB user. Wouldn't it be better to add a cli script to generate a first superlibrarian to log in with, and do away with db user logins altogether?

(In reply to Chris Cormack from comment #3)
> (In reply to Robin Sheat from comment #2)
> > The giant warning saying that you shouldn't do that indicates that you
> > shouldn't do that. 
> > 
> > A better fix is is to make that warning a bit more compulsory, e.g. cutting
> > off access to functions that aren't related to configuration/management if
> > you're the database user.
> > 
> > Maybe also make the warning bigger and having blinking marqueed text so it
> > doesn't get ignored.
> 
> Yep, what Robin is saying is that the real problem here is that you are
> logged in not as a real user but the db user.
> 
> I agree that we should definitely not let the db user ever circulate. That
> would be a much better solution. Also, lots of other features should be
> blocked too.
Comment 5 Robin Sheat 2014-02-24 19:00:00 UTC
(In reply to Kyle M Hall from comment #4)
> At this point I wonder why we still allow logins as the DB user. Wouldn't it
> be better to add a cli script to generate a first superlibrarian to log in
> with, and do away with db user logins altogether?

Because it's really super handy as an administrator to be able to go in and tweak or check some things for someone without having to have your own account set up in their system.

I do think that a large yellow warning ought to suffice, and this hasn't seemed to have come up nearly as often since that was implemented.
Comment 6 Galen Charlton 2014-05-06 15:12:22 UTC
(In reply to Robin Sheat from comment #5)
> (In reply to Kyle M Hall from comment #4)
> > At this point I wonder why we still allow logins as the DB user. Wouldn't it
> > be better to add a cli script to generate a first superlibrarian to log in
> > with, and do away with db user logins altogether?
> 
> Because it's really super handy as an administrator to be able to go in and
> tweak or check some things for someone without having to have your own
> account set up in their system.
> 
> I do think that a large yellow warning ought to suffice, and this hasn't
> seemed to have come up nearly as often since that was implemented.

However, such issues have not been completely eliminated, either.  It's not that big of a burden for folks who administer large numbers of Koha databases to simply create accounts from the CLI.

I'm a +1 one for getting rid of the database user.  If not that, at the very least we should stop exposing the database credentials that way and do something like putting in a new koha-conf.xml setting for username and (hashed!) password of a base superlibrarian "account".
Comment 7 Jonathan Druart 2015-07-13 08:15:15 UTC
Since we already agreed on not to use the DB user to navigate into Koha, I am stealing this bug report to submit a patch to restrict the actions of this user.
Comment 8 Jonathan Druart 2015-07-13 08:21:52 UTC
Created attachment 40963 [details] [review]
Bug 11590: Restrict the actions for the DB user

The DB user (the one defined in the KOHA_CONF file, section config)
should not be used to navigate into Koha.
It has been decided to let it actif to create the first user easily.
This patch suggests to restrict as much as possible the actions for this
user. If logged with this user, the administrator will only be able to
create the first user and that's all.
Automatically the new user created will be a superlibrarian.

Test plan:
1/ Use the DB user to log you in into Koha.
2/ Make sure you are just able to go to the about and help pages.
On the main page, you are pleased to create an user.
3/ Click on the link to create a new user
4/ Fill the form and save
5/ You are redirected to the loggin page
6/ Use the new user credentials and confirm it has been created as a
superlibrarian.
Comment 9 Robin Sheat 2015-07-16 04:56:32 UTC
It'd be nice to have a koha-conf.xml or environment override. In dev environments, I'm grabbing database and loading them in, and and prod environments I'm often needing to go in and get to the settings without having a login handy.

(Personally, I think that it's trying to solve a problem that doesn't need to be solved, but that's just me.)
Comment 10 Robin Sheat 2015-07-16 04:57:03 UTC
...and there is no circumstance where this is major importance.
Comment 11 Blou 2016-03-08 14:40:43 UTC
I'd like to reply on Robin's comment.

Here, I see a serious need for this as a matter of managing security.  Let just call that the disgruntled employee scenario.  I have no need for it RIGHT NOW, but as we plan for every possible outcome, to safeguard our customer's data or maintaining 24/7 access, one of them is the I-QUIT-AND-DESTROY-ALL-YOUR-SH.. scenario.

So OK, I have my you-quit-I-lock-out-your-account.  But changing a database password is a pain, always with some unforeseen consequences (yeah, I should plan those too).  You try to not have to do it.  Life is just simpler that way... Also, that's very hard to automate, or do manually through 100 databases.

SO, why give a user through a very easy to use UI, very easy to remember staff url, an Uber-Access to all that is sacred in our business ?

Anyway, too long text.  We can argue about my failures as a security manager, but I reserve the right to argue that this direct access to the system should be blockable.
Comment 12 Blou 2016-03-08 14:40:55 UTC
Comment on attachment 40963 [details] [review]
Bug 11590: Restrict the actions for the DB user

I'd like to test this.
Comment 13 Blou 2016-03-08 14:59:59 UTC
The patch does what I need, but would need two more things, I think:

1) Make that a preference.  To make it more acceptable to the people who don't believe in security :)
1b) The preference should by default be ON, but hey, that's arguable.

2) Prevent the unlimited creation of superuser using that user. I think as soon as there's one in the DB, the creation should be blocked.  After that, an access directly to the db is required if you forget your account.  Otherwise, the door is as open as before.
2b) I got a bash script to create support accounts from the backend.  I'd be happy to add it to a patch if wanted.

I'll sign the first patch off, because I think it's already a great move ahead.
Comment 14 Blou 2016-03-08 15:02:20 UTC
Created attachment 48788 [details] [review]
[SIGNED-OFF] Bug 11590: Restrict the actions for the DB user

The DB user (the one defined in the KOHA_CONF file, section config)
should not be used to navigate into Koha.
It has been decided to let it actif to create the first user easily.
This patch suggests to restrict as much as possible the actions for this
user. If logged with this user, the administrator will only be able to
create the first user and that's all.
Automatically the new user created will be a superlibrarian.

Test plan:
1/ Use the DB user to log you in into Koha.
2/ Make sure you are just able to go to the about and help pages.
On the main page, you are pleased to create an user.
3/ Click on the link to create a new user
4/ Fill the form and save
5/ You are redirected to the loggin page
6/ Use the new user credentials and confirm it has been created as a
superlibrarian.

Signed-off-by: Philippe Blouin <philippe.blouin@inlibro.com>
Comment 15 Jonathan Druart 2018-01-23 15:56:12 UTC
*** Bug 20071 has been marked as a duplicate of this bug. ***
Comment 16 Katrin Fischer 2019-02-04 22:38:32 UTC
We've stopped allowing the db user to login - marking duplicate of the bug that made it possible :)

*** This bug has been marked as a duplicate of bug 20489 ***