From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: open record looks like openat Date: Fri, 27 Jul 2007 10:59:12 -0400 Message-ID: <200707271059.12571.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Friday 27 July 2007 10:10:17 John D. Ramsdell wrote: > Notice this event has two PATH records, whereas all of the many other > open events I studied in my logs have one PATH record. =C2=A0It's as if= the > open system call can behave as the openat system call. =C2=A0I changed = my > analysis program to use the last PATH record to find the file name, so > that the same code can be used to analyze open and openat system > calls. But openat does give a different output: type=3DPATH msg=3Daudit(07/27/2007 10:42:17.954:153) : item=3D0 name=3Dte= st inode=3D6131=20 dev=3D08:06 mode=3Dfile,sgid,451 ouid=3Droot ogid=3Droot rdev=3D00:00=20 obj=3Duser_u:object_r:tmp_t:s0=20 type=3DCWD msg=3Daudit(07/27/2007 10:42:17.954:153) : cwd=3D/root=20 type=3DSYSCALL msg=3Daudit(07/27/2007 10:42:17.954:153) : arch=3Di386 sys= call=3Dopenat=20 success=3Dyes exit=3D4 a0=3D3 a1=3D80485d5 a2=3D42 a3=3D8048529 items=3D1= ppid=3D6310=20 pid=3D6312 auid=3Dsgrubb uid=3Droot gid=3Droot euid=3Droot suid=3Droot fs= uid=3Droot=20 egid=3Droot sgid=3Droot fsgid=3Droot tty=3Dpts0 comm=3Dtest=20 exe=3D/home/sgrubb/test/openat/test subj=3Duser_u:system_r:unconfined_t:s= 0=20 key=3D(null) Now, the out put changes if I do not include and do not defi= ne =20 __USE_ATFILE ! When I compile the test program I get a warning: implicit= =20 declaration of function =E2=80=98openat=E2=80=99. Low and behold the reco= rd changes to this: type=3DPATH msg=3Daudit(07/27/2007 10:33:59.030:81) : item=3D1 name=3Dtes= t inode=3D6131=20 dev=3D08:06 mode=3Dfile,sgid,451 ouid=3Droot ogid=3Droot rdev=3D00:00=20 obj=3Duser_u:object_r:tmp_t:s0=20 type=3DPATH msg=3Daudit(07/27/2007 10:33:59.030:81) : item=3D0 name=3D/r= oot inode=3D2=20 dev=3D08:06 mode=3Ddir,sticky,777 ouid=3Droot ogid=3Droot rdev=3D00:00=20 obj=3Dsystem_u:object_r:tmp_t:s0=20 type=3DCWD msg=3Daudit(07/27/2007 10:33:59.030:81) : cwd=3D/root=20 type=3DSYSCALL msg=3Daudit(07/27/2007 10:33:59.030:81) : arch=3Di386 sysc= all=3Dopenat=20 success=3Dyes exit=3D4 a0=3D3 a1=3D80485d5 a2=3D42 a3=3D8048529 items=3D2= ppid=3D4148=20 pid=3D4150 auid=3Dsgrubb uid=3Droot gid=3Droot euid=3Droot suid=3Droot fs= uid=3Droot=20 egid=3Droot sgid=3Droot fsgid=3Droot tty=3Dpts0 comm=3Dtest=20 exe=3D/home/sgrubb/test/openat/test subj=3Duser_u:system_r:unconfined_t:s= 0=20 key=3D(null)=20 The call in both cases was this: int main(void) { int dir_fd, fd; DIR *d =3D opendir("/tmp"); dir_fd =3D dirfd(d); fd =3D openat(dir_fd, "test", O_CREAT|O_RDWR); close (fd); closedir(d); return 0; } In neither record for openat did I get the "/tmp" directory which I thoug= ht I=20 should get. I don't understand why it mutates between the two forms, nor = do I=20 get what I think I should. I suspect the *at functions should have the=20 referenced directory recorded just as open records the cwd so paths can b= e=20 reassembled. It seems like we need a AUDIT_DIR aux record for path recrea= tion=20 when something relative is used as in the example program. Any kernel people want to chime in? -Steve