From sacadmin Sat Nov 25 19:31:38 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAQ3VcdH008654 for ; Sat, 25 Nov 2006 19:31:38 -0800 (PST) Received: from jurassic (jurassic [129.146.224.31]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id kAQ3Vc4B810145; Sat, 25 Nov 2006 19:31:38 -0800 (PST) Message-Id: <200611260331.kAQ3Vc4B810145@jurassic.eng.sun.com> Date: Sat, 25 Nov 2006 19:31:38 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: PSARC/2006/659 - fork extensions To: psarc@sac.sfbay.sun.com Cc: casper.dik@sun.com, michael.pogue@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 62Kv5BwhO6GA/Jh6n60NLQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_50 SunOS 5.11 sun4u sparc Status: RO Content-Length: 5209 I am sponsoring this fast-track case for myself. This proposal will time out 12/06/2006 The proposed release binding is "patch" (so it can be back-patched to Solaris 10 if required). There are problems with the family of fork() functions: fork() (aka fork1()) forkall() vfork() and also with the closely related spawn functions: posix_spawn() posix_spawnp() in the context of library development and multithreaded processes. If an otherwise MT-safe library wants to create a helper process (via fork()/exec() or posix_spawn()), either to perform some simple task (as in system()) or to produce output that is to be read back into the library interface that created it (as in popen()/pclose()), then it runs into the problems of SIGCHLD and wait(). The library interface typically wants to keep its internal actions reliable and private to itself, regardless of the behavior of other threads in the same process. However, when it creates a helper process, a SIGCHLD signal will be sent to the containing process when the child process terminates and it becomes vulnerable to calls to wait() by other threads in the containing process. If the process is catching SIGCHLD, any of its threads may execute the signal handler. That thread is thereby notified of the existence of the library's child process (a fact that the library would rather keep private) and, if the signal handler calls wait(), the child process's exit status will be lost to the library function that created the child. If the process is ignoring SIGCHLD, the child process is automatically reaped and the child process's exit status is lost to the library function that created the child. Finally, even in the absence of SIGCHLD issues, if some other thread is sleeping in a call to wait() or waitid(P_ALL), that other thread will reap the library's child process, causing the child process's exit status to be lost to the library function. So this brings us to the proposal for this PSARC case: Create public fork extension interfaces in libc which invoke new private libc/kernel system call traps: #include pid_t forkx(int flags); pid_t forkallx(int flags); pid_t vforkx(int flags); The forkx(), forkallx() and vforkx() functions accept a flags argument consisting of a bitwise inclusive OR of zero or more of the following flags, defined in the header : FORK_NOSIGCHLD Do not post a SIGCHLD signal to the parent process when the child process terminates, regardless of the disposition of the SIGCHLD signal in the parent. SIGCHLD signals are still possible for job control stop and continue actions if the parent has requested them. FORK_WAITPID Do not allow wait-for-multiple-pids by the parent, as in wait(), waitid(P_ALL), or waitid(P_PGID), to reap the child and do not allow the child to be reaped automatically due the disposition of the SIGCHLD signal being set to be ignored in the parent. Only a specific wait for the child, as in waitid(P_PID, pid), is allowed and it is required, else when the child exits it will remain a zombie until the parent exits. If the flags argument is zero, forkx() is identical to fork(), forkallx() is identical to forkall(), and vforkx() is identical to vfork(). Introduce two additional flags for posix_spawnattr_setflags(): The POSIX_SPAWN_NOSIGCHLD_NP and POSIX_SPAWN_WAITPID_NP flags are non-portable Solaris extensions to the posix_spawn() and posix_spawnp() interfaces. If the POSIX_SPAWN_NOSIGCHLD_NP flag is set in the spawn-flags attribute of the object referenced by attrp, no SIGCHLD signal will be posted to the parent process when the child process terminates, regardless of the disposition of the SIGCHLD signal in the parent. SIGCHLD signals are still possible for job control stop and continue actions if the parent has requested them. If the POSIX_SPAWN_WAITPID_NP flag is set in the spawn-flags attribute of the object referenced by attrp, no wait-for-multiple-pids operation by the parent, as in wait(), waitid(P_ALL), or waitid(P_PGID), will succeed in reaping the child, and the child will not be reaped automatically due the disposition of the SIGCHLD signal being set to be ignored in the parent. Only a specific wait for the child, as in waitid(P_PID, pid), is allowed and it is required, else when the child exits it will remain a zombie until the parent exits. The following functions in libc need to use both of these flags to overcome the problems described in this proposal (they are already written using posix_spawn()): popen() system() wordexp() invoke_utmp_update() The proposed changes require manual page changes for: fork(2) vfork(2) posix_spawn(3C) posix_spawnattr_getflags(3C) popen(3C) system(3C) See the materials directory for the old and new man pages. The old man pages have a '-' suffix. Use diff to see the changes. Roger Faulkner From sacadmin Mon Nov 27 13:28:19 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kARLSI3O013925 for ; Mon, 27 Nov 2006 13:28:19 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kARLSFTH027187; Mon, 27 Nov 2006 16:28:15 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kARLSFkG011657; Mon, 27 Nov 2006 16:28:15 -0500 (EST) Subject: Re: PSARC/2006/659 - fork extensions From: Bill Sommerfeld To: "Roger A. Faulkner" Cc: psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com In-Reply-To: <200611260331.kAQ3Vc4B810145@jurassic.eng.sun.com> References: <200611260331.kAQ3Vc4B810145@jurassic.eng.sun.com> Content-Type: text/plain Date: Mon, 27 Nov 2006 16:28:14 -0500 Message-Id: <1164662894.5404.37.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 246 This is a long-needed extension. Is there any way to observe that a child process has been marked as either FORK_NOSIGCHLD or FORK_WAITPID ? At the very least, it seems to me that these flags should turn up in pflags(1) output. - Bill From sacadmin Mon Nov 27 13:40:10 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kARLe9Ia014361 for ; Mon, 27 Nov 2006 13:40:10 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kARLe8v0014876; Mon, 27 Nov 2006 15:40:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kARLe8pQ014875; Mon, 27 Nov 2006 15:40:08 -0600 (CST) Date: Mon, 27 Nov 2006 15:40:08 -0600 From: Nicolas Williams To: Bill Sommerfeld Cc: "Roger A. Faulkner" , psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com Subject: Re: PSARC/2006/659 - fork extensions Message-ID: <20061127214007.GS5938@binky.Central.Sun.COM> References: <200611260331.kAQ3Vc4B810145@jurassic.eng.sun.com> <1164662894.5404.37.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1164662894.5404.37.camel@thunk> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 629 On Mon, Nov 27, 2006 at 04:28:14PM -0500, Bill Sommerfeld wrote: > This is a long-needed extension. > > Is there any way to observe that a child process has been marked as > either FORK_NOSIGCHLD or FORK_WAITPID ? At the very least, it seems to > me that these flags should turn up in pflags(1) output. And what happens when a process with FORK_NOSIGCHLD and/or FORK_WAITPID set is orphaned? Will these flags be reset so that init^Wsvc.startd can still get SIGCHLD and/or be able to reap the orphaned process with wait-for-multiple-pids wait calls? Or will such orphaned processes be automatically reaped on exit? Nico -- From sacadmin Mon Nov 27 15:49:55 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.105]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kARNnskZ018496 for ; Mon, 27 Nov 2006 15:49:55 -0800 (PST) Received: from jurassic (jurassic [129.146.17.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id kARNnRkt412448; Mon, 27 Nov 2006 15:49:27 -0800 (PST) Message-Id: <200611272349.kARNnRkt412448@jurassic.eng.sun.com> Date: Mon, 27 Nov 2006 15:49:27 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2006/659 - fork extensions To: sommerfeld@sun.com Cc: psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Afo8diciK9UErz5R4zjpkQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_50 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1039 > Subject: Re: PSARC/2006/659 - fork extensions > From: Bill Sommerfeld > To: "Roger A. Faulkner" > Cc: psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com > Date: Mon, 27 Nov 2006 16:28:14 -0500 > > This is a long-needed extension. > > Is there any way to observe that a child process has been marked as > either FORK_NOSIGCHLD or FORK_WAITPID ? At the very least, it seems to > me that these flags should turn up in pflags(1) output. > > - Bill Good point. I can make that happen (after PR_ORPHAN below): /* The following flags apply to the process, not to an individual lwp */ #define PR_ISSYS 0x00001000 /* this is a system process */ #define PR_VFORKP 0x00002000 /* process is the parent of a vfork() child */ #define PR_ORPHAN 0x00004000 /* process's process group is orphaned */ #define PR_NOSIGCHLD 0x00008000 /* process will not generate SIGCHLD on exit */ #define PR_WAITPID 0x00010000 /* waitid(P_PID, pid) is required */ Roger From sacadmin Mon Nov 27 15:56:07 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kARNu73t019096 for ; Mon, 27 Nov 2006 15:56:07 -0800 (PST) Received: from jurassic (jurassic [129.146.106.31]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id kARNtaqi432426; Mon, 27 Nov 2006 15:55:36 -0800 (PST) Message-Id: <200611272355.kARNtaqi432426@jurassic.eng.sun.com> Date: Mon, 27 Nov 2006 15:55:36 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2006/659 - fork extensions To: sommerfeld@sun.com, Nicolas.Williams@sun.com Cc: psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UEiAjd2hwwyDBNQfIk2iWg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_50 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1343 > Date: Mon, 27 Nov 2006 15:40:08 -0600 > From: Nicolas Williams > To: Bill Sommerfeld > Cc: "Roger A. Faulkner" , psarc@sac.sfbay.sun.com, Casper.Dik@Sun.COM, Michael.Pogue@Sun.COM > Subject: Re: PSARC/2006/659 - fork extensions > > On Mon, Nov 27, 2006 at 04:28:14PM -0500, Bill Sommerfeld wrote: > > This is a long-needed extension. > > > > Is there any way to observe that a child process has been marked as > > either FORK_NOSIGCHLD or FORK_WAITPID ? At the very least, it seems to > > me that these flags should turn up in pflags(1) output. > > And what happens when a process with FORK_NOSIGCHLD and/or FORK_WAITPID > set is orphaned? Will these flags be reset so that init^Wsvc.startd can > still get SIGCHLD and/or be able to reap the orphaned process with > wait-for-multiple-pids wait calls? Or will such orphaned processes be > automatically reaped on exit? > > Nico The flags are turned off when the parent dies and the child is reassigned to init. That was kind of implied in the spec: Only a specific wait for the child, as in waitid(P_PID, pid), is allowed and it is required, else when the child exits it will remain a zombie until the parent exits. Roger From sacadmin Mon Nov 27 17:36:38 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAS1abNr021031 for ; Mon, 27 Nov 2006 17:36:38 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAS1aXHQ029665; Mon, 27 Nov 2006 20:36:33 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kAS1aXnR012792; Mon, 27 Nov 2006 20:36:33 -0500 (EST) Subject: Re: PSARC/2006/659 - fork extensions From: Bill Sommerfeld To: "Roger A. Faulkner" Cc: psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com In-Reply-To: <200611272349.kARNnRkt412448@jurassic.eng.sun.com> References: <200611272349.kARNnRkt412448@jurassic.eng.sun.com> Content-Type: text/plain Date: Mon, 27 Nov 2006 20:36:32 -0500 Message-Id: <1164677792.5404.57.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 273 One more question occurred to me: is there a use case for using one of the flags without also using the other? All the cases I can think of will want to use both of them or neither of them; that suggests that we might be able to combine them for the sake of simplicity. From sacadmin Mon Nov 27 20:57:49 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAS4vnX3024415 for ; Mon, 27 Nov 2006 20:57:49 -0800 (PST) Received: from jurassic (jurassic [129.146.106.31]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id kAS4vnbE479681; Mon, 27 Nov 2006 20:57:49 -0800 (PST) Message-Id: <200611280457.kAS4vnbE479681@jurassic.eng.sun.com> Date: Mon, 27 Nov 2006 20:57:49 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2006/659 - fork extensions To: sommerfeld@sun.com Cc: psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hlPGSOlLkfEa5hy3obqwww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_50 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1551 > Subject: Re: PSARC/2006/659 - fork extensions > From: Bill Sommerfeld > To: "Roger A. Faulkner" > Cc: psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Michael.Pogue@sun.com > Date: Mon, 27 Nov 2006 20:36:32 -0500 > > One more question occurred to me: is there a use case for using one of > the flags without also using the other? All the cases I can think of > will want to use both of them or neither of them; that suggests that we > might be able to combine them for the sake of simplicity. Well, it's a reach but I could imagine an application that spawns off a bunch of child processes and wants to be notified of their completion via SIGCHLD signals but also wants to wait for them individually, not via wait() (the main thread may be sitting in wait() waiting for all children to terminate before calling exit() [wait() will sleep until the FORK_WAITPID processes terminate; it just won't reap them]). Solaris makes SIGCHLD reliable. That is, for every child termination, one SIGCHLD signal is generated, complete with a siginfo_t that contains the pid and its termination status (si_status, si_code). So a SIGCHLD signal handler could reliably reap all of the children by direct process-id and not rely on waitpid(-1, &status, WNOHANG). Yes, I know, this is a reach. And I can't think of a way I would want to use these flags except as a pair. However, I've learned over the years not to design interfaces based on how I anticipate they will be used. Someone will surprise you. Roger From sacadmin Tue Nov 28 16:13:40 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAT0DdXM024638 for ; Tue, 28 Nov 2006 16:13:39 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAT0Dceg027975; Tue, 28 Nov 2006 16:13:38 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kAT0HTFd021201; Tue, 28 Nov 2006 16:17:29 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kAT0HSFJ021200; Tue, 28 Nov 2006 16:17:28 -0800 (PST) Date: Tue, 28 Nov 2006 16:17:28 -0800 (PST) From: Gary Winiger Message-Id: <200611290017.kAT0HSFJ021200@marduk.eng.sun.com> To: Roger.Faulkner@eng.sun.com, psarc@sac.sfbay.sun.com Cc: casper.dik@sun.com, michael.pogue@sun.com Subject: Re: PSARC/2006/659 - fork extensions Status: RO Content-Length: 365 > Create public fork extension interfaces in libc which invoke > new private libc/kernel system call traps: > > #include > > pid_t forkx(int flags); > pid_t forkallx(int flags); > pid_t vforkx(int flags); Presumably there will be new audit events for these system calls and they will audit similarly to fork or fork1. Gary.. From sacadmin Tue Nov 28 17:01:01 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAT111jO025643 for ; Tue, 28 Nov 2006 17:01:01 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAT10xxR011909; Tue, 28 Nov 2006 17:00:59 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kAT14oBK021304; Tue, 28 Nov 2006 17:04:50 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kAT14oWH021303; Tue, 28 Nov 2006 17:04:50 -0800 (PST) Date: Tue, 28 Nov 2006 17:04:50 -0800 (PST) From: Gary Winiger Message-Id: <200611290104.kAT14oWH021303@marduk.eng.sun.com> To: Roger.Faulkner@eng.sun.com, psarc@sac.sfbay.sun.com, gww@eng.sun.com Subject: Re: PSARC/2006/659 - fork extensions Cc: casper.dik@sun.com, michael.pogue@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 451 > > Create public fork extension interfaces in libc which invoke > > new private libc/kernel system call traps: > > > > #include > > > > pid_t forkx(int flags); > > pid_t forkallx(int flags); > > pid_t vforkx(int flags); > > > Presumably there will be new audit events for these system > calls and they will audit similarly to fork or fork1. P.S. Don't forget to update .../cmd/bsmrecord/audit_record_attr.txt From sacadmin Tue Nov 28 23:47:04 2006 Received: from dm-holland-01.uk.sun.com (dm-holland-01.UK.Sun.COM [129.156.101.192]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAT7l3WH002268 for ; Tue, 28 Nov 2006 23:47:04 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.201.10]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAT7kqf4017149; Wed, 29 Nov 2006 07:46:52 GMT Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAT7dMiC006363; Wed, 29 Nov 2006 08:39:22 +0100 (MET) Message-Id: <200611290739.kAT7dMiC006363@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Gary Winiger cc: Roger.Faulkner@eng.sun.com, psarc@sac.sfbay.sun.com, Michael.Pogue@sun.com Subject: Re: PSARC/2006/659 - fork extensions In-Reply-To: <200611290104.kAT14oWH021303@marduk.eng.sun.com> References: <200611290104.kAT14oWH021303@marduk.eng.sun.com> Date: Wed, 29 Nov 2006 08:39:22 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 598 >> > Create public fork extension interfaces in libc which invoke >> > new private libc/kernel system call traps: >> > >> > #include >> > >> > pid_t forkx(int flags); >> > pid_t forkallx(int flags); >> > pid_t vforkx(int flags); >> >> >> Presumably there will be new audit events for these system >> calls and they will audit similarly to fork or fork1. > >P.S. Don't forget to update .../cmd/bsmrecord/audit_record_attr.txt Is there any reason to not continue to use the old audit records? (That would seem a gratuitous change of the audit log) Casper From sacadmin Wed Nov 29 02:39:50 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kATAdoH8005696 for ; Wed, 29 Nov 2006 02:39:50 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kATAdnN5017320 for ; Wed, 29 Nov 2006 02:39:49 -0800 (PST) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kATAdhEs014460 for ; Wed, 29 Nov 2006 10:39:43 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9H00301MWCUR00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 29 Nov 2006 10:39:43 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9H001JJMY5XC00@d1-emea-10.sun.com>; Wed, 29 Nov 2006 10:39:41 +0000 (GMT) Date: Wed, 29 Nov 2006 10:39:41 +0000 From: Darren J Moffat Subject: Re: PSARC/2006/659 - fork extensions In-reply-to: <200611290739.kAT7dMiC006363@vaticaan.holland.sun.com> Sender: Darren.Moffat@Sun.COM To: Casper.Dik@Sun.COM Cc: Gary Winiger , Roger.Faulkner@eng.sun.com, psarc@sac.sfbay.sun.com, Michael.Pogue@Sun.COM Message-id: <456D636D.9080106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200611290104.kAT14oWH021303@marduk.eng.sun.com> <200611290739.kAT7dMiC006363@vaticaan.holland.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 989 Casper.Dik@Sun.COM wrote: >>>> Create public fork extension interfaces in libc which invoke >>>> new private libc/kernel system call traps: >>>> >>>> #include >>>> >>>> pid_t forkx(int flags); >>>> pid_t forkallx(int flags); >>>> pid_t vforkx(int flags); >>> >>> Presumably there will be new audit events for these system >>> calls and they will audit similarly to fork or fork1. >> P.S. Don't forget to update .../cmd/bsmrecord/audit_record_attr.txt > > > Is there any reason to not continue to use the old audit records? > > (That would seem a gratuitous change of the audit log) I agree with Casper, I don't see why these should be audited differently to the existing counter parts. We have three events already AUE_fork, AUE_fork1, AUE_vfork, yet no event at all for posix_spawn. If we are going to change how fork is audited I'd rather we consolidated onto one event and have the record say which fork variant it was. -- Darren J Moffat From sacadmin Wed Nov 29 03:13:15 2006 Received: from dm-holland-01.uk.sun.com (dm-holland-01.UK.Sun.COM [129.156.101.192]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kATBDEPH006453 for ; Wed, 29 Nov 2006 03:13:15 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.204.1]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kATBD19j008703; Wed, 29 Nov 2006 11:13:01 GMT Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kATBD0S1016109; Wed, 29 Nov 2006 12:13:00 +0100 (MET) Message-Id: <200611291113.kATBD0S1016109@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Darren J Moffat cc: Gary Winiger , Roger.Faulkner@eng.sun.com, psarc@sac.sfbay.sun.com, Michael.Pogue@sun.com Subject: Re: PSARC/2006/659 - fork extensions In-Reply-To: <456D636D.9080106@Sun.COM> References: <200611290104.kAT14oWH021303@marduk.eng.sun.com> <200611290739.kAT7dMiC006363@vaticaan.holland.sun.com> <456D636D.9080106@Sun.COM> Date: Wed, 29 Nov 2006 12:13:00 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 515 >I agree with Casper, I don't see why these should be audited differently >to the existing counter parts. We have three events already AUE_fork, >AUE_fork1, AUE_vfork, yet no event at all for posix_spawn. Not surprising because posix_spawn is not a system call. (It's vfork()/execve) >If we are going to change how fork is audited I'd rather we consolidated >onto one event and have the record say which fork variant it was. Hear, hear. Casper Roger Faulkner: the only man brave enough to change fork(). From sacadmin Wed Nov 29 03:21:36 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kATBLaNI006480 for ; Wed, 29 Nov 2006 03:21:36 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kATBLZUI029760 for ; Wed, 29 Nov 2006 03:21:35 -0800 (PST) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kATBLU90021597 for ; Wed, 29 Nov 2006 11:21:30 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9H00701OU22700@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 29 Nov 2006 11:21:29 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9H001OZOVTXC00@d1-emea-10.sun.com>; Wed, 29 Nov 2006 11:21:29 +0000 (GMT) Date: Wed, 29 Nov 2006 11:21:29 +0000 From: Darren J Moffat Subject: Re: PSARC/2006/659 - fork extensions In-reply-to: <200611291113.kATBD0S1016109@vaticaan.holland.sun.com> Sender: Darren.Moffat@Sun.COM To: Casper.Dik@Sun.COM Cc: Gary Winiger , Roger.Faulkner@eng.sun.com, psarc@sac.sfbay.sun.com, Michael.Pogue@Sun.COM Message-id: <456D6D39.1070600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200611290104.kAT14oWH021303@marduk.eng.sun.com> <200611290739.kAT7dMiC006363@vaticaan.holland.sun.com> <456D636D.9080106@Sun.COM> <200611291113.kATBD0S1016109@vaticaan.holland.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 762 Casper.Dik@Sun.COM wrote: >> I agree with Casper, I don't see why these should be audited differently >> to the existing counter parts. We have three events already AUE_fork, >> AUE_fork1, AUE_vfork, yet no event at all for posix_spawn. > > Not surprising because posix_spawn is not a system call. Doh I forgot it was still a userland wrapper and not a system call. > (It's vfork()/execve) > >> If we are going to change how fork is audited I'd rather we consolidated >> onto one event and have the record say which fork variant it was. > > Hear, hear. > > Casper > > Roger Faulkner: the only man brave enough to change fork(). I wouldn't dare touch it so I'm glad Roger does because every time he does it makes Solaris better! -- Darren J Moffat From sacadmin Wed Nov 29 08:55:00 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kATGt0nJ013272 for ; Wed, 29 Nov 2006 08:55:00 -0800 (PST) Received: from jurassic (jurassic [129.146.17.55]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id kATGsqDh234599; Wed, 29 Nov 2006 08:54:53 -0800 (PST) Message-Id: <200611291654.kATGsqDh234599@jurassic.eng.sun.com> Date: Wed, 29 Nov 2006 08:54:53 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2006/659 - fork extensions To: Darren.Moffat@sun.com, Casper.Dik@sun.com Cc: gww@eng.sun.com, psarc@sac.sfbay.sun.com, Michael.Pogue@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fDjftdgCP4dtVH4cnutVXQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_53 SunOS 5.11 sun4u sparc Status: RO Content-Length: 853 > From: Casper.Dik@Sun.COM > To: Darren J Moffat > cc: Gary Winiger , Roger.Faulkner@eng.sun.com, psarc@sac.sfbay.sun.com, Michael.Pogue@Sun.COM > Subject: Re: PSARC/2006/659 - fork extensions > Date: Wed, 29 Nov 2006 12:13:00 +0100 > > > >I agree with Casper, I don't see why these should be audited differently > >to the existing counter parts. We have three events already AUE_fork, > >AUE_fork1, AUE_vfork, yet no event at all for posix_spawn. > > Not surprising because posix_spawn is not a system call. > > (It's vfork()/execve) > > >If we are going to change how fork is audited I'd rather we consolidated > >onto one event and have the record say which fork variant it was. > > Hear, hear. > > Casper > > Roger Faulkner: the only man brave enough to change fork(). Fools rush in ... R. From sacadmin Wed Nov 29 17:01:43 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAU11hrR026904 for ; Wed, 29 Nov 2006 17:01:43 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAU11fN8023205; Wed, 29 Nov 2006 17:01:41 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kAU15XQx023206; Wed, 29 Nov 2006 17:05:33 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kAU15XEj023205; Wed, 29 Nov 2006 17:05:33 -0800 (PST) Date: Wed, 29 Nov 2006 17:05:33 -0800 (PST) From: Gary Winiger Message-Id: <200611300105.kAU15XEj023205@marduk.eng.sun.com> To: Casper.Dik@sun.com, Darren.Moffat@sun.com Cc: Michael.Pogue@sun.com, Roger.Faulkner@eng.sun.com, gww@eng.sun.com, psarc@sac.sfbay.sun.com Subject: Re: PSARC/2006/659 - fork extensions Status: RO Content-Length: 1090 > > Is there any reason to not continue to use the old audit records? > > > > (That would seem a gratuitous change of the audit log) > > I agree with Casper, I don't see why these should be audited differently > to the existing counter parts. We have three events already AUE_fork, > AUE_fork1, AUE_vfork, yet no event at all for posix_spawn. > > If we are going to change how fork is audited I'd rather we consolidated > onto one event and have the record say which fork variant it was. Well, anything is possible. If there is a project to redo system call auditing to change it, please file that case and we can discuss it there. In the mean time, I'd like the project team to answer what this project proposes to do for auditing. Presently there are 3 events related to fork. AUE_FORKALL, AUE_VFORK, AUE_FORK1. They take no arguments and return a pid. The proposed forkx, forkallx, vforkx take an argument. Perhaps their audit records will reflect the value of that argument. In any case bsmrecord likely needs an update to reflect the new system calls. Gary.. From sacadmin Wed Nov 29 21:32:43 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAU5Whss006630 for ; Wed, 29 Nov 2006 21:32:43 -0800 (PST) Received: from jurassic (jurassic [129.146.224.31]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id kAU5Wh7G428502; Wed, 29 Nov 2006 21:32:43 -0800 (PST) Message-Id: <200611300532.kAU5Wh7G428502@jurassic.eng.sun.com> Date: Wed, 29 Nov 2006 21:32:43 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2006/659 - fork extensions To: Casper.Dik@sun.com, Darren.Moffat@sun.com, gww@eng.sun.com Cc: Michael.Pogue@sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: myR/HBBU49wukx2SVRhtSQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_53 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1864 > Date: Wed, 29 Nov 2006 17:05:33 -0800 (PST) > From: Gary Winiger > To: Casper.Dik@Sun.COM, Darren.Moffat@Sun.COM > Cc: Michael.Pogue@Sun.COM, Roger.Faulkner@eng.sun.com, gww@eng.sun.com, psarc@sac.sfbay.sun.com > Subject: Re: PSARC/2006/659 - fork extensions > > > > Is there any reason to not continue to use the old audit records? > > > > > > (That would seem a gratuitous change of the audit log) > > > > I agree with Casper, I don't see why these should be audited differently > > to the existing counter parts. We have three events already AUE_fork, > > AUE_fork1, AUE_vfork, yet no event at all for posix_spawn. > > > > If we are going to change how fork is audited I'd rather we consolidated > > onto one event and have the record say which fork variant it was. > > Well, anything is possible. If there is a project to redo > system call auditing to change it, please file that case and > we can discuss it there. > > In the mean time, I'd like the project team to answer what > this project proposes to do for auditing. > > Presently there are 3 events related to fork. AUE_FORKALL, > AUE_VFORK, AUE_FORK1. They take no arguments and return a pid. > The proposed forkx, forkallx, vforkx take an argument. Perhaps > their audit records will reflect the value of that argument. > In any case bsmrecord likely needs an update to reflect the > new system calls. > > Gary.. My plan (actually already implemented) is to continue to generate three fork-related events: AUE_FORK1, AUE_FORKALL, and AUE_VFORK. forksys(0, flags), aka forkx(flags), generates AUE_FORK1 forksys(1, flags), aka forkallx(flags), generates AUE_FORKALL forksys(2, flags), aka vforkx(flags), generates AUE_VFORK There is no new event for the new forksys() system call. The flags value is not recorded anywhere (is this OK?). Roger From sacadmin Thu Nov 30 01:40:00 2006 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAU9dxY1012086 for ; Thu, 30 Nov 2006 01:40:00 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.213.1]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAU9drkk020934; Thu, 30 Nov 2006 09:39:53 GMT Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAU9dqSY002329; Thu, 30 Nov 2006 10:39:52 +0100 (MET) Message-Id: <200611300939.kAU9dqSY002329@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: "Roger A. Faulkner" cc: Darren.Moffat@sun.com, gww@eng.sun.com, Michael.Pogue@sun.com, psarc@sac.sfbay.sun.com Subject: Re: PSARC/2006/659 - fork extensions In-Reply-To: <200611300532.kAU5Wh7G428502@jurassic.eng.sun.com> References: <200611300532.kAU5Wh7G428502@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Nov 2006 10:39:52 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 521 >My plan (actually already implemented) is to continue to generate >three fork-related events: AUE_FORK1, AUE_FORKALL, and AUE_VFORK. > >forksys(0, flags), aka forkx(flags), generates AUE_FORK1 >forksys(1, flags), aka forkallx(flags), generates AUE_FORKALL >forksys(2, flags), aka vforkx(flags), generates AUE_VFORK > >There is no new event for the new forksys() system call. >The flags value is not recorded anywhere (is this OK?). I'm fine with that because it does not convey much useful information. Casper From sacadmin Thu Nov 30 03:51:18 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUBpI6w014038 for ; Thu, 30 Nov 2006 03:51:18 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAUBpHqx010770 for ; Thu, 30 Nov 2006 03:51:18 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAUBpCTN012067 for ; Thu, 30 Nov 2006 11:51:12 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9J00E01KUV1L00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 30 Nov 2006 11:51:12 +0000 (GMT) Received: from [192.168.73.103] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9J00CHHKXBS020@d1-emea-09.sun.com>; Thu, 30 Nov 2006 11:51:11 +0000 (GMT) Date: Thu, 30 Nov 2006 11:51:11 +0000 From: Darren J Moffat Subject: Re: PSARC/2006/659 - fork extensions In-reply-to: <200611300939.kAU9dqSY002329@vaticaan.holland.sun.com> Sender: Darren.Moffat@Sun.COM To: Casper.Dik@Sun.COM Cc: "Roger A. Faulkner" , gww@eng.sun.com, Michael.Pogue@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <456EC5AF.7090505@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200611300532.kAU5Wh7G428502@jurassic.eng.sun.com> <200611300939.kAU9dqSY002329@vaticaan.holland.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 853 Casper.Dik@Sun.COM wrote: >> My plan (actually already implemented) is to continue to generate >> three fork-related events: AUE_FORK1, AUE_FORKALL, and AUE_VFORK. >> >> forksys(0, flags), aka forkx(flags), generates AUE_FORK1 >> forksys(1, flags), aka forkallx(flags), generates AUE_FORKALL >> forksys(2, flags), aka vforkx(flags), generates AUE_VFORK >> >> There is no new event for the new forksys() system call. >> The flags value is not recorded anywhere (is this OK?). > > > I'm fine with that because it does not convey much useful information. Likewise, I don't think the tiny bit of additional information is actually security relevant. Just like I don't think that making the distinction between the types of fork at the audit event level is actually helpful (nay it is harmful since it complicates analysis). -- Darren J Moffat From sacadmin Thu Nov 30 12:38:15 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUKcFTv028127 for ; Thu, 30 Nov 2006 12:38:15 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAUKcCXn013945; Thu, 30 Nov 2006 12:38:12 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kAUKg6eX024141; Thu, 30 Nov 2006 12:42:06 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kAUKg6Tm024140; Thu, 30 Nov 2006 12:42:06 -0800 (PST) Date: Thu, 30 Nov 2006 12:42:06 -0800 (PST) From: Gary Winiger Message-Id: <200611302042.kAUKg6Tm024140@marduk.eng.sun.com> To: Casper.Dik@sun.com, Darren.Moffat@sun.com, Roger.Faulkner@eng.sun.com, gww@eng.sun.com Cc: Michael.Pogue@sun.com, psarc@sac.sfbay.sun.com Subject: Re: PSARC/2006/659 - fork extensions Status: RO Content-Length: 588 > My plan (actually already implemented) is to continue to generate > three fork-related events: AUE_FORK1, AUE_FORKALL, and AUE_VFORK. > > forksys(0, flags), aka forkx(flags), generates AUE_FORK1 > forksys(1, flags), aka forkallx(flags), generates AUE_FORKALL > forksys(2, flags), aka vforkx(flags), generates AUE_VFORK > > There is no new event for the new forksys() system call. > The flags value is not recorded anywhere (is this OK?). I agree with others, the flags don't seem security relevant. As I think I noted, don't forget to update bsmrecord(1M)s database. Gary.. From sacadmin Thu Nov 30 15:27:55 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kAUNRt8D004479 for ; Thu, 30 Nov 2006 15:27:55 -0800 (PST) Received: from jurassic (jurassic [129.146.106.31]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id kAUNRslG122863; Thu, 30 Nov 2006 15:27:54 -0800 (PST) Message-Id: <200611302327.kAUNRslG122863@jurassic.eng.sun.com> Date: Thu, 30 Nov 2006 15:27:54 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2006/659 - fork extensions To: Casper.Dik@sun.com, Darren.Moffat@sun.com, gww@eng.sun.com Cc: Michael.Pogue@sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nf43Gt3Jh8f2wpDYtlFjpQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_53 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1522 > Date: Thu, 30 Nov 2006 12:42:06 -0800 (PST) > From: Gary Winiger > To: Casper.Dik@sun.com, Darren.Moffat@sun.com, Roger.Faulkner@eng.sun.com, gww@eng.sun.com > Cc: Michael.Pogue@sun.com, psarc@sac.sfbay.sun.com > Subject: Re: PSARC/2006/659 - fork extensions > > > My plan (actually already implemented) is to continue to generate > > three fork-related events: AUE_FORK1, AUE_FORKALL, and AUE_VFORK. > > > > forksys(0, flags), aka forkx(flags), generates AUE_FORK1 > > forksys(1, flags), aka forkallx(flags), generates AUE_FORKALL > > forksys(2, flags), aka vforkx(flags), generates AUE_VFORK > > > > There is no new event for the new forksys() system call. > > The flags value is not recorded anywhere (is this OK?). > > I agree with others, the flags don't seem security relevant. > As I think I noted, don't forget to update bsmrecord(1M)s > database. Since I haven't introduced any new events, is there any reason to modify usr/src/cmd/bsmrecord/audit_record_attr.txt ? I did change it, but just to use the proper name for AUE_FORKALL: 813c813 < label=AUE_FORK --- > label=AUE_FORKALL 816c816 < note=The fork(2) return values are undefined because the audit record --- > note=The forkall(2) return values are undefined because the audit record AUE_FORK is the historical name, same value as AUE_FORKALL, stemming from the time, long ago, when fork() was forkall() if you didn't link with -lpthread. Since Solaris 10, fork() is fork1() regardless of how you link. Roger From sacadmin Tue Dec 5 16:26:11 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kB60QBhu011503 for ; Tue, 5 Dec 2006 16:26:11 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB60Q8TW022303; Tue, 5 Dec 2006 16:26:08 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kB60UAVg000648; Tue, 5 Dec 2006 16:30:10 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kB60UACU000647; Tue, 5 Dec 2006 16:30:10 -0800 (PST) Date: Tue, 5 Dec 2006 16:30:10 -0800 (PST) From: Gary Winiger Message-Id: <200612060030.kB60UACU000647@marduk.eng.sun.com> To: Casper.Dik@sun.com, Darren.Moffat@sun.com, Roger.Faulkner@eng.sun.com, gww@eng.sun.com Cc: Michael.Pogue@sun.com, psarc@sac.sfbay.sun.com Subject: Re: PSARC/2006/659 - fork extensions Status: RO Content-Length: 1360 > > > My plan (actually already implemented) is to continue to generate > > > three fork-related events: AUE_FORK1, AUE_FORKALL, and AUE_VFORK. > > > > > > forksys(0, flags), aka forkx(flags), generates AUE_FORK1 > > > forksys(1, flags), aka forkallx(flags), generates AUE_FORKALL > > > forksys(2, flags), aka vforkx(flags), generates AUE_VFORK > > > > > > There is no new event for the new forksys() system call. > > > The flags value is not recorded anywhere (is this OK?). > > > > I agree with others, the flags don't seem security relevant. > > As I think I noted, don't forget to update bsmrecord(1M)s > > database. > > Since I haven't introduced any new events, is there any reason > to modify usr/src/cmd/bsmrecord/audit_record_attr.txt ? > > I did change it, but just to use the proper name for AUE_FORKALL: > > 813c813 > < label=AUE_FORK > --- > > label=AUE_FORKALL > 816c816 > < note=The fork(2) return values are undefined because the audit record > --- > > note=The forkall(2) return values are undefined because the audit record We're getting down into code review here, so please have audit-core@sun.com review the changes. audit_event(4) defines AUE_FORK and no where defines AUE_FORKALL even though it is in the kernel header file. bsmrecord is a stable interface and I'm not sure what the impact would be. Gary..