From: Eric Paris <eparis@redhat.com>
To: "John D. Ramsdell" <ramsdell@mitre.org>
Cc: linux-audit@redhat.com
Subject: Re: clone flags
Date: Thu, 19 Jul 2007 15:37:17 -0400 [thread overview]
Message-ID: <1184873837.3923.1.camel@localhost.localdomain> (raw)
In-Reply-To: <ogtbqe8w7v5.fsf@oolong.mitre.org>
On Thu, 2007-07-19 at 14:45 -0400, John D. Ramsdell wrote:
> Eric Paris <eparis@redhat.com> writes:
>
> > Actually it's a problem with mapping things. The flags are in a0.
>
> Eric, you seem to have nailed this issue.
> I played around with tracing the clone system call, and found
> something else since my last message. I traced a program that creates
> threads within a single address space with clone, and that call puts
> the clone flags into a2. The auparse library interprets these flags
> as one would expect.
Actually, not quite. Its still the same mapping problem. auparse is
busted and the flags are always in a0 for the audit log. auparse is
actually giving you total and complete crap output. Notice in auparse
you got a long list of flags.
CLONE_VM|CLONE_FS|CLONE_SIGHAND|CLONE_PTRACE|CLONE_PARENT|CLONE_THREAD|
CLONE_NEWNS|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_CHILD_CLEARTID|
CLONE_DETACHED|CLONE_UNTRACED|CLONE_CHILD_SETTID|CLONE_STOPPED|
CLONE_NEWUTS
And the strace output below only showed a short list of flags. Also
note that one is NOT a sub/super set of the other. CLONE_DETACHED above
and CLONE_FILES below?
CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|
CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID
Anyway I took the strace flags and worked it out:
#define CLONE_VM 0x00000100
#define CLONE_FS 0x00000200
#define CLONE_FILES 0x00000400
#define CLONE_SIGHAND 0x00000800
#define CLONE_THREAD 0x00010000
#define CLONE_SYSVSEM 0x00040000
#define CLONE_SETTLS 0x00080000
#define CLONE_PARENT_SETTID 0x00100000
#define CLONE_CHILD_CLEARTID 0x00200000
0x003D0F00
Low and behold the audit a0 is 3d0f00
Looks like auparse was wrongly trying to convert the pointer for
parent_tidptr=0xb7f7fbd8 (notice we had CLONE_PARENT_SETTID set) into
clone flags and that list of flags was the best it could do.
So I'd say change all your stuff to look only at a0 for clone and
someone (sgrubb already knows) needs to fix auparse to look for the
flags in a0 not in a2.
-Eric
next prev parent reply other threads:[~2007-07-19 19:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 13:24 clone flags John D. Ramsdell
2007-07-19 17:59 ` Eric Paris
2007-07-19 18:45 ` John D. Ramsdell
2007-07-19 19:37 ` Eric Paris [this message]
2007-07-19 19:42 ` John D. Ramsdell
2007-07-20 11:07 ` John D. Ramsdell
2007-07-23 11:44 ` Clone and fcntl64 flags patch John D. Ramsdell
2007-07-23 13:40 ` John D. Ramsdell
2007-07-24 21:36 ` Steve Grubb
2007-07-25 11:49 ` John D. Ramsdell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1184873837.3923.1.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=ramsdell@mitre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox