Task #12312 (new)
Opened 10 years ago
Last modified 8 years ago
Bug: password reset assumes root user ID of 0
Reported by: | mtbcarroll | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Unscheduled |
Component: | General | Version: | 5.0.1 |
Keywords: | n.a. | Cc: | omero-team@… |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
Looking at password in db.py it appears to assume that root's user ID is 0. Shouldn't it be checking the Roles object? Or, at least, if the server isn't available, joining with the experimenter table to find out which is actually named root?
Change History (4)
comment:1 Changed 10 years ago by jamoore
- Milestone changed from Unscheduled to 5.0.3
- Owner jamoore deleted
comment:2 Changed 10 years ago by mtbcarroll
A lot of code avoids assuming 0: for instance, the admin service prevents changing root's name from root (which wouldn't much matter if we could still assume id 0, Unix should still work with root renamed), views.py bothers with expressions like conn.getAdminService().getSecurityRoles().rootId, and on startup the server regards the name as the authoritative datum in doing a,
select id from experimenter where omeName = 'root'
which make me wonder what assumptions have already been pervading the code.
comment:3 Changed 10 years ago by jamoore
- Milestone changed from 5.0.3 to 5.x
Looking at password in db.py it appears to assume that root's user ID is 0. Shouldn't it be checking the Roles object? Or, at least, if the server isn't available, joining with the experimenter table to find out which is actually named root?
Making calls directly to PSQL has been something we've largely avoided from the CLI, so I don't think that's in scope to change here. If you think we should add a proper call in before doing this, we can look at doing so, but in general db assumes that no server is present, i.e. you've lost your password etc. so I'd tend to vote no on that. That then only leaves whether or not root or 0 should be definitive, which is a pretty large undertaking. (I'm inclined to vote for 0 so that someone could make there root name more i18n friendly.)
All that taken into account, I'm pushing. I'm open to suggestions/discussion, but I think mostly this should be a "rationalize Roles usage" RFE.
comment:4 Changed 8 years ago by jamoore
- Milestone changed from 5.x to Unscheduled
Then let's implement or close. (There may need to be a general conversation about which is the most definitive: ID or name. On Unix, it would be ID)