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
Created attachment 24595 [details] [review] Bug 11590 - Librarian able to checkout item without setting branch first It is possible to begin circulating items to a patron without first setting your logged in branch! Test Plan: 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. 4) Apply this patch 5) Repeat steps 1-2, you should now be redirected to select a branch instead of being taken directly to circulation.pl
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.
(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.
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.
(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.
(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".
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.
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.
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.)
...and there is no circumstance where this is major importance.
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 on attachment 40963 [details] [review] Bug 11590: Restrict the actions for the DB user I'd like to test this.
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.
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>
*** Bug 20071 has been marked as a duplicate of this bug. ***
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 ***