I’m working on this cool new offering for my company and of course we use Microsoft Office Groove 2007 to quickly and easily share documents, presentations and such, without having to use an intermediary website like SharePoint or an internal fileshare over a VPN. I was invited to this particular Groove workspace as a ‘participant’ (my security role for this workspace) and for the place where you can put your files that basically comes down to permissions you see in the screenshot.
At first, those permissions seemed to work fine, because I couldn’t delete a document that was put there by someone else. In this case however, I was asked to update this particular document and I chose to save the updated document under a different name in the workspace. Now I had 2 documents in the same folder, 1 old en 1 new. There was also an “OLD” folder in the workspace, so I decided I would move the old document to the OLD folder and this is where I hit the security restrictions, and after some fiddling, the loophole:
Because you don’t have the “Delete files/subfolders” permission as a ‘Participant’ in Groove, you can’t delete someone else’s files. This prevented me from moving the old document (which was owned by someone else) to the OLD folder. However I could copy the document to the OLD folder since the security permissions do allow that, so now I only needed to delete the old document in the root folder.
I tried to open the document, make a change to it and save it back again to Groove, but even though the “Modified By” value was updated (to myself) I didn’t became the owner of the document and still couldn’t delete it – Groove’s security model scores again.
Next however I tried something devious (and it worked): I created a file with the same name as the document that I wanted to delete from Groove and dragged that file to the workspace. Groove asked me if I wanted to overwrite the file and needless to say I happily clicked ‘yes’ and presto! I was now the owner of the file and I could delete the file!
It seems that Groove sees an overwrite action only as a ‘Modify files’ action and not as a ‘Delete files/subfolders’ action. I will report this to Microsoft so they can fix this; in the mean time you can remove the ‘Modify files’ right from the participant role if you’re afraid that some of your Workspace members want to take advantage of this loophole.
Entries (RSS)
How do you remove the “Modify files” permission for the Participant Role? I don’t see this permission for the Participant Role.
See screenshot on http://weblog.stranger.nl/files/images/GroovePermissions.png
Regards,
Stefan Stranger
http://weblog.stranger.nl
First go to the Files tool in your workspace, then right-click on the root folder and select ‘Properties’, then go to the ‘Permissions’ tab. Repeat the procedure for every Files tool in every workspace that you need the extra security for.
Be aware that by changing this permission you don’t have the right of changing someone else his file content. And maybe you need that permission. So be aware. The loophole is there but you need to think if you really need to change that permission.
Groove is tool for working together on files and other stuff and changing this permission would undermine the functionality of Groove.
But that still means that Kevin is right about the loophole being there. And it need to be addressed.
See ya,
Jeroen
Hey Kevin,
thanks for pointing this out. I’ve spoken with development about this, and we now have a bug open. Thanks for raising the awareness. i’ ve also posted a link, and some additional information, on http://blogs.technet.com/groove. I agree with Jeroen’s post that I wouldn’t nescessarily recomend disabling this permission for members in the space.
Hi,
I’ve got a question about permissions, not directly related on this bug, but I coudn’t find a better pleace to post
Is there a way to give “read” permission/restriction into the security of Groove?
In a different folders in my root folder. 1 of these folders may not readable for some users in the workspace.
Is this possible? I think they forgotten the read-permission in the permissionoptions…
is there maybe a work around?
Hi Luc,
If you are in a workspace then you have always the read right. That is the lowest right sort of speak. The Guest role has that permission by default.
You have three roles by default, Manager, Participant and guest. As a manager of a workspace you can edit the security per rol and not per user. If we don’t want user in a workspace to go to some specific folder then an option van be to create a new workspace. And putting links to those files and folders in the original workspace. Then only invited users to the new workspace can use the links to get to the data.
I hope this some kind of solution for you. If not or you have any questions please let me know.
see ya
Jeroen Jansen