Ticket #5434 (closed Bug: fixed)
Any logged in user can view prefs_mailhost_form, which exposes the esmtp password
| Reported by: | hannosch | Owned by: | brcwhit |
|---|---|---|---|
| Priority: | critical | Milestone: | 2.1.3 |
| Component: | Infrastructure | Keywords: | |
| Cc: |
Description
Just noticed I had a bug report from George Lee rotting in my inbox:
"Came across this -- in Plone 2.1.2, any logged in user can view prefs_mailhost_form, which exposes the ESMTP password if it exists. (It's obscured in the browser, but can easily be unmasked.)"
I guess this means direct attribute access to the esmtp password might also be only weakly secured.
Change History
comment:2 Changed 6 years ago by shh
Just how brilliant is that? Why the fsck can control panel stuff be viewed by anyone without "Manage portal" at all? May there be more pref panels affected?
comment:3 Changed 6 years ago by raphael
It should be sufficient to adjust
CMFPlone/skins/plone_prefs/prefs_mailhost_form.cpt.metadata
where currently 'View' is protected by
[security] View=0:Authenticated
Changing this to 'Manage portal' should suffice (untested).
As Stefan already implied, other pref_panels are affected as well. Looks like this is the default for everything :-( Do we have an explicit policy here? I agree with Stefan here that in general these panels should require 'Manage portal'.
comment:4 Changed 6 years ago by rocky
- Owner changed from somebody to brcwhit
Whit is actively working on this one.
comment:5 Changed 6 years ago by brcwhit
- Status changed from new to assigned
proper syntax is actually the following:
View = 0: Manager
Not sure what the 0: does, but this follows examples in CMFCore tests.
comment:6 Changed 6 years ago by hannosch
- Status changed from assigned to closed
- Resolution set to fixed
- Milestone changed from 2.1.x to 2.1.3
comment:8 Changed 6 years ago by alecm
There may well be cases where non-Managers should access some of these prefpanels (i.e. when people have created custom roles for managing users, etc), which is why it's generally a bad idea to use a specific role to restrict security. Doing a permission check in the template (like the user prefs does) is often a better solution, though in this case it shouldn't matter a bit.
