 




<?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: command restrict</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/command-restrict/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/command-restrict/</link>
	<description></description>
	<lastBuildDate>Tue, 21 May 2013 13:34:32 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: tomliotta</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/command-restrict/#comment-70973</link>
		<dc:creator>tomliotta</dc:creator>
		<pubDate>Sun, 29 Nov 2009 09:19:04 +0000</pubDate>
		<guid isPermaLink="false">#comment-70973</guid>
		<description><![CDATA[You can indeed exclude programmers from PWRDWNSYS, etc., by object authority. It just isn&#039;t very effective against competent developers. It&#039;s temporary for as long as a developer allows it to be effective. Do you also ensure that developers cannot create message files for production apps? If not, then object authority is probably insufficient. A message file can defeat it. Plenty of other possibilities exist. (Many!)

Now, object authority is still a good idea. It is an excellent assistance for mistake avoidance. For developers, though, a combination of policy and trust is where the effort should be placed.

Tom]]></description>
		<content:encoded><![CDATA[<p>You can indeed exclude programmers from PWRDWNSYS, etc., by object authority. It just isn&#8217;t very effective against competent developers. It&#8217;s temporary for as long as a developer allows it to be effective. Do you also ensure that developers cannot create message files for production apps? If not, then object authority is probably insufficient. A message file can defeat it. Plenty of other possibilities exist. (Many!)</p>
<p>Now, object authority is still a good idea. It is an excellent assistance for mistake avoidance. For developers, though, a combination of policy and trust is where the effort should be placed.</p>
<p>Tom</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dand</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/command-restrict/#comment-69549</link>
		<dc:creator>dand</dc:creator>
		<pubDate>Tue, 27 Oct 2009 17:42:54 +0000</pubDate>
		<guid isPermaLink="false">#comment-69549</guid>
		<description><![CDATA[Object level authority is a perfectly acceptable way to control access to commands.  Do you let programmers on your systems have access to PWRDWNSYS or ENDTCPSVR or ENDHOSTSRV commands?  We only give programmers read rights to data in their job sphere but they have *JOBCTL so they can use a number of &quot;dangerous&quot; commands if authorized to them.]]></description>
		<content:encoded><![CDATA[<p>Object level authority is a perfectly acceptable way to control access to commands.  Do you let programmers on your systems have access to PWRDWNSYS or ENDTCPSVR or ENDHOSTSRV commands?  We only give programmers read rights to data in their job sphere but they have *JOBCTL so they can use a number of &#8220;dangerous&#8221; commands if authorized to them.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/9 queries in 0.012 seconds using memcached
Object Caching 282/285 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-21 13:43:18 -->