Jump to content


What permissions should be set on the Swarm user

swarm permissions

  • Please log in to reply
12 replies to this topic

#1 Andrew DeFaria

Andrew DeFaria

    Advanced Member

  • Members
  • PipPipPip
  • 125 posts

Posted 05 November 2014 - 11:37 PM

I have Swarm setup with the appropriate triggers, etc. Normally when engineers submit or shelve a changelist and they include #review and @mentions everything works fine. But sometimes it doesn't work and some people have been complaining that they haven't gotten notified.

I think the problem is that sometimes the changelist has a Restricted Access Type. So far this seems to happen only on shelved changeslists but I have not verified that that is indeed the case. However, I can, as my own user (and admin with superuser privileges) not see the description of this shelved, restricted access changelist and I'm thinking if I can't see it then neither can the Swarm user (p4swarmuser) and thus no notifications will be sent out for any @mentions.

So then what permissions would p4swarmuser need in order to be able to see the description and properly send out notifications?

I've attached and example of a change list which is restricted such that I cannot see the description. It is a shelved changelist.

Attached Thumbnails

  • Changelist.png


#2 Andrew DeFaria

Andrew DeFaria

    Advanced Member

  • Members
  • PipPipPip
  • 125 posts

Posted 05 November 2014 - 11:40 PM

Oh, p4swarmuser is already a member of the admins group

#3 P4PetrH

P4PetrH

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 06 November 2014 - 01:28 AM

Hi Andrew,

restricted changes (submitted or shelved) are accessible only by users who own the change or have list access to at least one of the files in the change (I guess you are well aware of that). So unless you restrict access for the Swarm user in the protections table, it should have access to all restricted changes.

When review is created form a shelved change, we copy the change type over, so reviews created from restricted changes will be also 'restricted'. We have an extra layer in Swarm to filter out resources (changes, reviews, comments, activity items) that are related to restricted changes the current user doesn't have access to. Its implemented via running 'p4 changes' command against given change(s) with the user's connection so it should match exactly what changes users can see in depot (from the Swarm machine IP though).

Now to your point regarding the emails. The problem is not what changes the Swarm user can see, but the fact that we can't reliably determine whether the user has access to a given change without having the user's connection to Perforce. When emails are sent, we only have user ids (or emails), so it would be very challenging to somehow emulate their connection to check if they can access particular change or not.

Facing this situation, we had 2 choices when dealing with emails for restricted changes - either ignore it and send emails to everyone involved, or send no emails. We adopted the second option as a default behaviour, but you have an option to turn sending emails for restricted changes on to everyone - just merge the following into your config.php:
array(
 'security' => array(
  'email_restricted_changes' => true
 )
);

So in your case, if you add the above to your config, you should start seeing emails for restricted changes being sent. However, be aware that it will leak otherwise disclosed information to users who don't have access to a given change in Perforce.

You can also check the documentation here: http://www.perforce....tricted_changes

#4 Andrew DeFaria

Andrew DeFaria

    Advanced Member

  • Members
  • PipPipPip
  • 125 posts

Posted 10 November 2014 - 07:24 AM

View PostP4PetrH, on 06 November 2014 - 01:28 AM, said:

Hi Andrew,

restricted changes (submitted or shelved) are accessible only by users who own the change or have list access to at least one of the files in the change (I guess you are well aware of that). So unless you restrict access for the Swarm user in the protections table, it should have access to all restricted changes.

Shouldn't an admin have at least list access everything? AFAICT the Swarm user is not restricted by the permissions table. In fact I added review access explicitly for all depots - still it fails.

View PostP4PetrH, on 06 November 2014 - 01:28 AM, said:

Now to your point regarding the emails. The problem is not what changes the Swarm user can see, but the fact that we can't reliably determine whether the user has access to a given change without having the user's connection to Perforce. When emails are sent, we only have user ids (or emails), so it would be very challenging to somehow emulate their connection to check if they can access particular change or not.

I don't understand why Swarm is concerned at all with whether the users mentioned have access to the particular change. Send the email regardless. If they can access it - bam you win. If they can't then its a configuration problem that needs to be addressed in house. Not sending the email is never the right thing.

View PostP4PetrH, on 06 November 2014 - 01:28 AM, said:

Facing this situation, we had 2 choices when dealing with emails for restricted changes - either ignore it and send emails to everyone involved, or send no emails. We adopted the second option as a default behaviour, but you have an option to turn sending emails for restricted changes on to everyone - just merge the following into your config.php:
array(
'security' => array(
'email_restricted_changes' => true
)
);

So in your case, if you add the above to your config, you should start seeing emails for restricted changes being sent. However, be aware that it will leak otherwise disclosed information to users who don't have access to a given change in Perforce.

What otherwise not disclosed information do you see it leaking other than this numbered change list which I cannot see anything else about it being reviewed?!? I find that odd.

#5 P4PetrH

P4PetrH

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 13 November 2014 - 12:30 AM

The review email contains change description and list of files in that changelist. Leaking just these 2 pieces of information to users not having access to a given restricted change seems quite a serious security issue to me as they would never be able to get this information from the command line.

But as I noted in my previous post, if this is not a security concern for you, you can enable sending these emails by adding 1 line to config.php.

#6 Andrew DeFaria

Andrew DeFaria

    Advanced Member

  • Members
  • PipPipPip
  • 125 posts

Posted 13 November 2014 - 04:38 PM

Seems to me that if the person is going to participate in the review then they are gonna need to see way more than just the change description and list of files? Otherwise how could they possibly participate in the review?!? You might think that this is for when one accidentally includes the wrong person however it's not like mail servers are trying to protect their users from accidentally including your boss on an email about an interview for another company...

#7 P4PetrH

P4PetrH

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 13 November 2014 - 07:07 PM

Swarm won't let access to reviews associated with restricted changes for users not permitted accessing these changes in Perforce, regardless if they are review participants or not. And as I mentioned before, Swarm will also filter out related activity events and comments.

#8 Andrew DeFaria

Andrew DeFaria

    Advanced Member

  • Members
  • PipPipPip
  • 125 posts

Posted 10 December 2014 - 11:21 PM

@P4PetrH you said:

Quote

restricted changes (submitted or shelved) are accessible only by users who own the change or have list access to at least one of the files in the change

However I do not see this as the case! I changed one file in it down a long path:

//AudEngr/Import/VSS_Branch_laramie_90.5.2/Devel/Platform/Targets/D300/Projects/TestAutomation/UpdateDLLs.cmd

shelved it including the description:

Testing Swarm notification email
#review
@lnitta @bzwernemann @jortiz



The three @mentions got added to the review but received no email. This is in spite of the fact that:

Adefaria-lt:p4 protects -u bzwernemann //AudEngr/Import/VSS_Branch_laramie_90.5.2/Devel/Platform/Targets/D300/Projects/TestAutomation/UpdateDLLs.cmd
write group platform * //AudEngr/Import/...
Adefaria-lt:

So clearly bzwernemann has write access to everything under //AudEngr/Import/... which implies read and list access. So why did Swarm fail to send him and email? And how would I debug this?

#9 P4PetrH

P4PetrH

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 11 December 2014 - 10:18 PM

Hi Andrew,

I assume that the change you shelved is restricted, correct? If so, did you set 'email_restricted_changes' config option under security to true?
If either the change is not restricted or you have set 'email_restricted_changes' in config to true, then it seems like a bug and I can investigate more.

Also note that sending email notifications for restricted reviews depends solely on the settings in config and is on or off for everyone. From technical reasons (as I described in previous posts), Swarm cannot reliably determine (at least at the moment) whether the given user has access to a restricted change or not without having user's connection.

#10 Andrew DeFaria

Andrew DeFaria

    Advanced Member

  • Members
  • PipPipPip
  • 125 posts

Posted 12 December 2014 - 01:00 AM

AFAICT 'email_restricted_changes' is an all or nothing thing. If set then the fact that a changelist is restricted is irrelevant and everybody gets the email. We do not want that.

But the manual and even you state: "restricted changes (submitted or shelved) are accessible only by users who own the change or have list access to at least one of the files in the change". But this is exactly the case in my test - the users involved in the review did have not only list access but write access. Yet they were not notified.

If my first paragraph is true then everybody would get email and the fact that the invited reviewers have or do not have list access to the files in the changelist becomes irrelevant.

Where exactly can we get the behavior that everybody invited to the review will get an email provided they have at least list access to a file in the changelist? Doesn't seem doable given your description.

And as for "the fact that we can't reliably determine whether the user has access to a given change without having the user's connection to Perforce" I don't see why you need the user's connection to Perforce. What about the p4 protects command? That's protects with an "s":

Adefaria-lt:p4 protects -u bzwernemann //AudEngr/Import/VSS_Branch_laramie_90.5.2/Devel/Platform/Targets/D300/Projects/TestAutomation/UpdateDLLs.cmd
write group platform * //AudEngr/Import/...
Adefaria-lt:


Couldn't swarm execute that p4 protects and parse the output to insure that the user has list level or better access to the files in the changelist? Seems like it should and I know I didn't need bzwenemann's password. Sure the swarm user would need to have superuser privilege...

#11 P4PetrH

P4PetrH

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts

Posted 13 December 2014 - 12:03 AM

Hi Andrew,

by 'all or nothing' I meant this: Assume that the review is restricted (i.e. its head change is of 'restricted' type). Then there are 2 cases depending on the value of 'email_restricted_changes' flag:
  • this flag is set to true => Swarm will send notification emails to all participants as if the head change was public
  • this flag is set to false or unset (default) => Swarm will not send any email notification to anyone
The above 2 rules apply regardless of whether the particular participant has access to the restricted change in Perforce or not.

Lets make a particular example for two different users Foo, Bar participating in review R. Below is a list with several different scenarios together with intended Swarm behaviour, please let me know if its not aligned with your experience:
  • user Joe updates a review R by shelving a public change & 'email_restricted_changes' is set to false or unset
    => both
    Foo and Bar DO receive email notification
  • user Joe updates a review R by shelving a public change & 'email_restricted_changes' is set to true
    => both Foo and Bar DO receive email notification

  • user Joe updates a review R by shelving a restricted change &
    'email_restricted_changes' is set to false or unset &
    Foo has access to the change C &
    Bar does not have access to the change C &
    => NEITHER of Foo or Bar receive email notification

  • user Joe updates a review R by shelving a restricted change © &
    'email_restricted_changes' is set to true &
    Foo has access to the change C &
    Bar does not have access to the change C
    => both Foo and Bar DO receive email notification
The same would apply for notifications related to commenting on review, submitting a review etc.

Points 3. and 4. are probably surprising for the most people as they may not expect this behaviour. It shows what I meant by all or nothing - sending notifications does depend only on whether the change is restricted or not and whether the 'email_restricted_changes' flag is set to true or false/unset and does not depend on whether the user has access to that change.

Please let me know if you see a different behaviour in your installation.

Emulating access for users via running protects -u command and comparing it to change files is in theory possible, but its challenging and would never be perfect as for example Swarm cannot know what IP address the user will be reading the notification email from (just as an example of one issue), so what protections lines should be applied (in case there are some lines restricted to particular IP address)?

#12 Andrew DeFaria

Andrew DeFaria

    Advanced Member

  • Members
  • PipPipPip
  • 125 posts

Posted 19 December 2014 - 05:02 PM

View PostP4PetrH, on 13 December 2014 - 12:03 AM, said:

  • user Joe updates a review R by shelving a restricted change &
    'email_restricted_changes' is set to false or unset &
    Foo has access to the change C &
    Bar does not have access to the change C &
    => NEITHER of Foo or Bar receive email notification
‚Äč


This part is odd to me. Why shouldn't Foo get email about the review. Clearly he has access. And the documentation says "restricted changes (submitted or shelved) are accessible only by users who own the change or have list access to at least one of the files in the change". So in my mind Foo should be notified for this review.

View PostP4PetrH, on 13 December 2014 - 12:03 AM, said:

Points 3. and 4. are probably surprising for the most people as they may not expect this behaviour. It shows what I meant by all or nothing - sending notifications does depend only on whether the change is restricted or not and whether the 'email_restricted_changes' flag is set to true or false/unset and does not depend on whether the user has access to that change.


If you know you're surprising most people then I would think you'd need to better explain such things in the documentation. I mean, you know you are confusing people...

View PostP4PetrH, on 13 December 2014 - 12:03 AM, said:

Emulating access for users via running protects -u command and comparing it to change files is in theory possible, but its challenging and would never be perfect as for example Swarm cannot know what IP address the user will be reading the notification email from (just as an example of one issue), so what protections lines should be applied (in case there are some lines restricted to particular IP address)?

The whole concept of restricting a workspace - to a host or IP or whatever - in an environment where you have developers working together seems foreign to me.

However I believe that p4 protects -u will tell you if the user has access to it from some workspace? I'm not sure about that. Being that p4 protects works in the context of some workspace (is that right - I don't have access to Perforce right now) I guess it may not be able to tell but if it works outside of a workspace context and it's saying user Bar can see this file at least in some contexts then I would think that's enough of a check to send the email.

#13 Bruce Mc

Bruce Mc

    Advanced Member

  • Members
  • PipPipPip
  • 84 posts
  • LocationSeattle Area

Posted 25 December 2014 - 08:50 PM

Hi Andrew,

In the permissions table, you can restrict access to specifiic depot paths by IP address. That IP address can be speciified as a range so access restrictions could be applied to a subnet.

For the scope of determing access when using an IP address filter, the perforce server uses the IP address of the machine originating the access request. Whether that request to access files through this filter comes from workspace activity (i.e. p4 sync) or non-workspace activity (i.e. p4 print) does not matter to this filter.

With respect to restricted changelists, visibility to a restricted pending changelist with shelved files by an user that is not the owner of the changelist is granted by an user's access to one or more of the shelved files in that changelist. Given that access to a depot file can be dependent on which IP that request for access comes from, it can only be said Foo has access when the IP address that Foo is rquesting the access from is known.

I believe the case can be made that a decision to send / not-send an email about a review associated with a restricted change cannot be made when it is based on an user's access to the restricited change when an IP address needed to determine that access is not known. It then comes down to an administrtive decision expressed in a setting to always send email about a review with a restricted change or never send email about a review with a restricted change.

Bruce



Also tagged with one or more of these keywords: swarm, permissions

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users