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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
