View Issue Details

IDProjectCategoryView StatusLast Update
0026993mantisbtsecuritypublic2020-11-25 15:28
Reporterpolzin Assigned Todregad  
PriorityhighSeveritymajorReproducibilityhave not tried
Status feedbackResolutionreopened 
Product Version2.24.1 
Summary0026993: bug_reminder_page inappropriately shows wrong view_status in some configurations
Description

What I have done:

  • config_inc: $g_bug_reminder_threshold = REPORTER;
  • config_inc: $g_default_reminder_view_status = VS_PRIVATE;
  • User with Access "Reporter"
  • bug_reminder_page.php

What expected:

  • No view_status printed

What seen:

  • Visibility: internal
  1. This is inappropriate, because user does not have the right so set or see view status
  2. The information is even wrong, because as the user does not hav ethe right to set the view status, the final view status is "public", not "private"

This is not really a security risc, but a confusion about security, but only, if reports may send reminders.

Additional Information

Fix:

Change in bug_reminder_page.php

        # Only display view status checkbox/info if reminders are stored as bugnotes
        if( $t_store_reminders ) {

to

        # Only display view status checkbox/info if reminders are stored as bugnotes
        # and there is a right to set the view status
        if( $t_store_reminders && access_has_bug_level( config_get( 'set_view_status_threshold' ), $f_bug_id ) ) {
TagsNo tags attached.

Activities

dregad

dregad

2020-10-10 06:37

developer   ~0064537

@polzin, in my opinion the current behavior is correct.

user does not have the right so set or see view status

$g_set_view_status_threshold is defined as Threshold needed to set the view status while reporting a bug or a bug note; it does not say anything about (preventing the) ability to view the existence of the view status.

the user does not hav ethe right to set the view status, the final view status is "public", not "private"

In that case, IMO the "final view status" should be the one defined as default ($g_default_reminder_view_status), not _VSPUBLIC

In the scenario you describe where a user is allowed to send reminders but not to set the view status (e.g. $g_bug_reminder_threshold = REPORTER; $g_set_view_status_threshold = DEVELOPER;with a reporter user), then the system behaves as expected, as it displays the bugnote's view status, without allowing the user to change it.

Based on the above, I believe this issue should be closed as "no change required". Let me know your thoughts.

dregad

dregad

2020-11-13 02:37

developer   ~0064648

Since you did not provide any feedback following my earlier reply, I'm resolving this issue.

polzin

polzin

2020-11-25 15:28

reporter   ~0064702

I am very sorry for the long delay, @dregad.

$g_set_view_status_threshold is defined as Threshold needed to set the view status while reporting a bug or a bug note; it does not say anything about (preventing the) ability to view the existence of the view status.

Literally, from the definition of the setting, you are right. But the program behaves different in all other cases: If you cannot set the view_status, you cannot see it. This is also a more logical behaviour. Some parts of the program interpret it this way (e.g. when reporting a bug).

In that case, IMO the "final view status" should be the one defined as default ($g_default_reminder_view_status), not _VSPUBLIC

Again, literally, from the definition of the setting, $g_set_view_status_threshold you have a good point. Yet, it makes sense to interpret "setting a view status" as the "possibility to set an internal view status". Some parts of the program interpret it this way.

I am looking to it from the view of a previously working use case that has proven to be very practical: Reporters are outsiders which should not see private notes. Developers communicate mostly internally and only some notes are set to public.

So, even you have a difference between your expectation and the current behaviour. But fixing it your way, would make it worse in my interpretation. :-)
But I have to admit, for bug's it works that way: If you do not have the right to set_view_state, you don't see the view_state on report, but it's set to "DEFAULT".

Okay, what is the consequence? There is a very strange behaviour in a non standard setting (Mantis shows "private", but the result is "public"). But perhaps it's not relevant enough to change it.

Issue History

Date Modified Username Field Change
2020-05-28 15:50 polzin New Issue
2020-10-10 06:37 dregad Assigned To => dregad
2020-10-10 06:37 dregad Status new => feedback
2020-10-10 06:37 dregad Note Added: 0064537
2020-11-13 02:37 dregad Status feedback => resolved
2020-11-13 02:37 dregad Resolution open => no change required
2020-11-13 02:37 dregad Note Added: 0064648
2020-11-25 14:20 atrol Status resolved => closed
2020-11-25 15:28 polzin Status closed => feedback
2020-11-25 15:28 polzin Resolution no change required => reopened
2020-11-25 15:28 polzin Note Added: 0064702