On Friday, March 16, 2012 05:50:56 PM Peter Moody wrote: > line 1162 in auditctl.c has this: > > #ifndef DEBUG >   /* Make sure we are root */ >   if (getuid() != 0) { >     fprintf(stderr, "You must be root to run this program.\n"); >     return 4; >   } > #endif > > Is there any particular reason to use getuid() there as opposed to > geteuid()? I suppose it doesn't matter. I never envisioned having a helper application, so that why its the way it is. Since we are optionally linking in libcap-ng, I suppose we could even check the capability rather than the euid.

Also note that for certification purposes the file permissions are restricted.

-Steve > In my particular case, we have a setuid helper that allows > a normal user to run 'auditctl -l' (with a clean environment), and > this prevents the setuid helper from working.

On Wednesday, March 21, 2012 12:38:06 PM Peter Moody wrote: > On Tue, Mar 20, 2012 at 11:07 AM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > On Friday, March 16, 2012 05:50:56 PM Peter Moody wrote: > >> line 1162 in auditctl.c has this: > >> > >> #ifndef DEBUG > >>   /* Make sure we are root */ > >>   if (getuid() != 0) { > >>     fprintf(stderr, "You must be root to run this program.\n"); > >>     return 4; > >>   } > >> #endif > >> > >> Is there any particular reason to use getuid() there as opposed to > >> geteuid()? > > > > I suppose it doesn't matter. I never envisioned having a helper > > application, so that why its the way it is. Since we are optionally > > linking in libcap-ng, I suppose we could even check the capability > > rather than the euid. > > Just the CAP_AUDIT_CONTROL capability? On the -m command, it instead needs CAP_AUDIT_WRITE.

> > Also note that > > for certification purposes the file permissions are restricted. > > The permissions of the auditctl binary? Yes. We ship it 0750. -Steve