[redhat-lspp] Re: Behavior of groupdel question

[Steve Grubb]

Hi,

Adding Peter to this.

On Monday 02 October 2006 12:04, Loulwa Salem wrote:
> I was trying running a regression groupdel test from our audit test suite
> and noticed the following behavior
>
> when executing groupdel, unexpected return codes are returned.
>
> The behavior I get now is as follows (I tried this manually per steps
> below):
>
> 1- execute groupdel as non root on non existing group
> # /usr/sbin/groupdel blahgroup
>   groupdel: group blahgroup does not exist
> # echo $?
>   6

This doesn't sound right.

> 2- Create a group (as root) then try to delete it as non root
> # groupadd mygroup		(Running as root)
> # exit				(go back to regular user)
> # /usr/sbin/groupdel mygroup
>   groupdel: unable to lock group file
> # echo $?
>   10

Same.

> The groupdel man pages document the "10" exit code as "can't update group
> file", but there is no return code "6".
>
> Is the behavior above what we expect?

I don't think so.

> Shouldn't a regular user be denied to execute groupdel regardless if group
> exists or not (with permission denied exit code)? At least that's what our
> test expected in the past.

I think that there should be a check for root user and EPERM error if common 
user. The return code of 6 should be documented in the man pages regardless.

> I am running shadow_utils-4.0.16-3 and Michael tried this on version
> 4.0.17-5 as well and saw the same behavior.

This sounds like bugzilla material.

Thanks,
-Steve