<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Security loophole found in Groove 2007 Files Tool</title>
	<atom:link href="http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/</link>
	<description>Innovative Technology presented by Innovative People</description>
	<lastBuildDate>Wed, 10 Mar 2010 15:33:20 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jeroen Jansen</title>
		<link>http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/comment-page-1/#comment-26276</link>
		<dc:creator>Jeroen Jansen</dc:creator>
		<pubDate>Fri, 12 Oct 2007 11:12:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/#comment-26276</guid>
		<description>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&#039;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</description>
		<content:encoded><![CDATA[<p>Hi Luc,</p>
<p>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.<br />
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&#8217;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.</p>
<p>I hope this some kind of solution for you. If not or you have any questions please let me know.</p>
<p>see ya</p>
<p>Jeroen Jansen</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: luc.slenders</title>
		<link>http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/comment-page-1/#comment-26185</link>
		<dc:creator>luc.slenders</dc:creator>
		<pubDate>Wed, 10 Oct 2007 08:22:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/#comment-26185</guid>
		<description>Hi,

I&#039;ve got a question about permissions, not directly related on this bug, but I coudn&#039;t find a better pleace to post :)

Is there a way to give &quot;read&quot; 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?</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I&#8217;ve got a question about permissions, not directly related on this bug, but I coudn&#8217;t find a better pleace to post <img src='http://www.buit.org/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>Is there a way to give &#8220;read&#8221; permission/restriction into the security of Groove?</p>
<p>In a different folders in my root folder. 1 of these folders may not readable for some users in the workspace.</p>
<p>Is this possible?  I think they forgotten the read-permission in the permissionoptions&#8230; <img src='http://www.buit.org/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' /> </p>
<p>is there maybe a work around?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: abbott lowell</title>
		<link>http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/comment-page-1/#comment-1825</link>
		<dc:creator>abbott lowell</dc:creator>
		<pubDate>Wed, 14 Feb 2007 10:31:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/#comment-1825</guid>
		<description>Hey Kevin,
thanks for pointing this out.  I&#039;ve spoken with development about this, and we now have a bug open. Thanks for raising the awareness.  i&#039; ve also posted a link, and some additional information, on http://blogs.technet.com/groove.  I agree with Jeroen&#039;s post that I wouldn&#039;t nescessarily recomend disabling this permission for members in the space.</description>
		<content:encoded><![CDATA[<p>Hey Kevin,<br />
thanks for pointing this out.  I&#8217;ve spoken with development about this, and we now have a bug open. Thanks for raising the awareness.  i&#8217; ve also posted a link, and some additional information, on <a href="http://blogs.technet.com/groove" rel="nofollow">http://blogs.technet.com/groove</a>.  I agree with Jeroen&#8217;s post that I wouldn&#8217;t nescessarily recomend disabling this permission for members in the space.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeroen Jansen</title>
		<link>http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/comment-page-1/#comment-1634</link>
		<dc:creator>Jeroen Jansen</dc:creator>
		<pubDate>Sun, 11 Feb 2007 08:05:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/#comment-1634</guid>
		<description>Be aware that by changing this permission you don&#039;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</description>
		<content:encoded><![CDATA[<p>Be aware that by changing this permission you don&#8217;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.<br />
Groove is tool for working together on files and other stuff and changing this permission would undermine the functionality of Groove.<br />
But that still means that Kevin is right about the loophole being there. And it need to be addressed.</p>
<p>See ya,</p>
<p>Jeroen</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Reeuwijk</title>
		<link>http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/comment-page-1/#comment-1605</link>
		<dc:creator>Kevin Reeuwijk</dc:creator>
		<pubDate>Sat, 10 Feb 2007 13:35:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/#comment-1605</guid>
		<description>First go to the Files tool in your workspace, then right-click on the root folder and select &#039;Properties&#039;, then go to the &#039;Permissions&#039; tab. Repeat the procedure for every Files tool in every workspace that you need the extra security for.</description>
		<content:encoded><![CDATA[<p>First go to the Files tool in your workspace, then right-click on the root folder and select &#8216;Properties&#8217;, then go to the &#8216;Permissions&#8217; tab. Repeat the procedure for every Files tool in every workspace that you need the extra security for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stefan Stranger</title>
		<link>http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/comment-page-1/#comment-1604</link>
		<dc:creator>Stefan Stranger</dc:creator>
		<pubDate>Sat, 10 Feb 2007 10:11:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.buit.org/2007/02/09/security-loophole-found-in-groove-2007-files-tool/#comment-1604</guid>
		<description>How do you remove the &quot;Modify files&quot; permission for the Participant Role? I don&#039;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</description>
		<content:encoded><![CDATA[<p>How do you remove the &#8220;Modify files&#8221; permission for the Participant Role? I don&#8217;t see this permission for the Participant Role.</p>
<p>See screenshot on <a href="http://weblog.stranger.nl/files/images/GroovePermissions.png" rel="nofollow">http://weblog.stranger.nl/files/images/GroovePermissions.png</a></p>
<p>Regards,<br />
Stefan Stranger<br />
<a href="http://weblog.stranger.nl" rel="nofollow">http://weblog.stranger.nl</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
