Menu
▾
▴
#711 setup.pl dumps too many roles
setup.pl's role dump includes *all* ledgersmb roles, for *all* companies.
E.g. I have two companies, Inc and Example; when logging into Inc, I see all lsmb_inc__* roles in the dump as well as the lsmb_example__ roles.
If this is correct, it's at least counter intuitive.
It is correct, given the way that roles are handled back-up-wise. The question is how we make this more intuitive. Maybe note on the button that it is a global role dump?
Could we change it to only dump for the current db ?
Hasorli: There is no way to do that. Roles are global, and users can be imported from one db to another. If we change that, it causes issues for transactional loading of the restore file.
I think what we need is some additional support for a self-contained db backup which can be restored with everything but user passwords.
My proposal (probably in the vacinity of .29) is as follows:
1) A table which is rebuilt every time a user is granted permissions (for that user's record) which stores the entity id of the user (not username) and the granted role name
2) A stored procedure which recreates users from the users table if they do not exist in the Postgres system catalog. Such users would have temporary passwords, but full permissions they used to have.
In this case, for database restores of dedicated hosting the simple thing to do is restore a global roles dump and then restore the individual database(s) as is currently the case.
However if you are moving from shared hosting you could:
1) Restore your db
2) Rebuild stored procs and roles using setup.pl
3) de-mangle user names as appropriate.
4) Log in to the setup.pl and rebuild dangling users. Temporary passwords could be assigned there.
this way the database db would be sufficiently self-contained to move from a shared hosting service to a dedicated one, but the truly sensitive global information would not be required.
> I think what we need is some additional support for a self-contained db
Yes, we do.
I would like to support this user cases:
- Moving backup from shared hosting to other shared hosting
- Moving backup from shared hosting to a new db on the same shared hosting (backup and import db for test).
- Moving backup from shared hosting to local install
- Moving backup from local install to shared hosting
- Make it possible for the "company admin" user to do all this on a shared hosting install as self-service
(with as few rights to the db cluster as possible. Creating of an empty db my be done by another tool, that revoke grant db access from the company admin user, after the empty db are created.)
To reset the password is ok if you have av few users, not if you have 30 or 100 that login to your projects.
> Hasorli: There is no way to do that. Roles are global, and users can be
Can we filter the Roles export and only include the Roles that belongs to the current db ?
Is there a connection between employee and user we can use to make the filter?
If we need to reset the password for admin users, that's ok.
hasorli:
First, I think the setup.pm would be a poor tools for a shared hosting environment. The idea in all cases I think, is to ensure that LedgerSMB::Database has the functionality required to do this.
I am not quite sure what to do about backing up users' passwords. We will need to talk more about this. Maybe on IRC?
ok, so here is what I am working on to solve this problem.
An optional sql file to load in shared hosting environments which ahs three functions:
lsmb__backup_roles()
lsmb__clear_role_backup()
lsmb__restore_roles()
These would not be called from setup.pl since they pose risks of security information disclosure. For shared hosting environments they can be loaded and called easily enough using $request->call_procedure() or the like. I would add this to the release notes.
trunk svn 5544, to be merged to branches/1.3