* Re: [PATCH V3 0/3] Add support for session ID user filtering
From: Richard Guy Briggs @ 2016-10-21 6:46 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, linux-kernel, sgrubb, eparis
In-Reply-To: <1817842.78IB8nV8t8@sifl>
On 2016-10-20 15:27, Paul Moore wrote:
> On Thursday, August 18, 2016 01:43:12 PM Richard Guy Briggs wrote:
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
> > RFE Session ID User Filter
> >
> > https://github.com/linux-audit/audit-kernel/issues/4
> > RFE: add a session ID filter to the kernel's user filter
> >
> > See also the set of userspace suport patches:
> > Add support for sessionid user filters, sessionid_set and loginuid_set
> > https://www.redhat.com/archives/linux-audit/2016-August/msg00005.html
> > (userspace update expected to be posted 2016-08-18)
> > and the test case:
> > https://github.com/rgbriggs/audit-testsuite/tree/ghak4-test-for-sessionID-u
> > ser-filter
> >
> > This third patch is expected to have a merge conflict with:
> > "audit: add exclude filter extension to feature bitmap"
> > posted on 2016-08-18.
> >
> > Richard Guy Briggs (3):
> > audit: add support for session ID user filter
> > audit: add AUDIT_SESSIONID_SET support
> > audit: add sessionid filter extension to feature bitmap
> >
> > include/linux/audit.h | 10 ++++++++++
> > include/uapi/linux/audit.h | 6 +++++-
> > kernel/auditfilter.c | 5 +++++
> > kernel/auditsc.c | 6 ++++++
> > 4 files changed, 26 insertions(+), 1 deletions(-)
>
> In light of our current decision to drop the session ID "set" filter, I'm
> taking another look at these patches and Richard's comment to simply drop
> patch 2/3 and apply 1/3 and 3/3.
>
> Richard, as I mentioned earlier, perhaps not clearly enough, I think we should
> put a check in audit_set_loginuid() to skip the (int)-1 value from appearing
> in session_id during normal operation. In other words, roll/reset the value
> in session_id one value early so we don't run into problems with the (int)-1
> unset sentinel value.
I noted your comment earlier and I agree skipping the sentinel is
required, but if we are rolling this counter, we have bigger issues
unless there is a way to determine if a sessionID value is still in use
by at least one task.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH V3 0/3] Add support for session ID user filtering
From: Paul Moore @ 2016-10-21 17:03 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: Paul Moore, linux-audit, linux-kernel
In-Reply-To: <20161021064658.GR23701@madcap2.tricolour.ca>
On Fri, Oct 21, 2016 at 2:46 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-10-20 15:27, Paul Moore wrote:
>> On Thursday, August 18, 2016 01:43:12 PM Richard Guy Briggs wrote:
>> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter
>> > RFE Session ID User Filter
>> >
>> > https://github.com/linux-audit/audit-kernel/issues/4
>> > RFE: add a session ID filter to the kernel's user filter
>> >
>> > See also the set of userspace suport patches:
>> > Add support for sessionid user filters, sessionid_set and loginuid_set
>> > https://www.redhat.com/archives/linux-audit/2016-August/msg00005.html
>> > (userspace update expected to be posted 2016-08-18)
>> > and the test case:
>> > https://github.com/rgbriggs/audit-testsuite/tree/ghak4-test-for-sessionID-u
>> > ser-filter
>> >
>> > This third patch is expected to have a merge conflict with:
>> > "audit: add exclude filter extension to feature bitmap"
>> > posted on 2016-08-18.
>> >
>> > Richard Guy Briggs (3):
>> > audit: add support for session ID user filter
>> > audit: add AUDIT_SESSIONID_SET support
>> > audit: add sessionid filter extension to feature bitmap
>> >
>> > include/linux/audit.h | 10 ++++++++++
>> > include/uapi/linux/audit.h | 6 +++++-
>> > kernel/auditfilter.c | 5 +++++
>> > kernel/auditsc.c | 6 ++++++
>> > 4 files changed, 26 insertions(+), 1 deletions(-)
>>
>> In light of our current decision to drop the session ID "set" filter, I'm
>> taking another look at these patches and Richard's comment to simply drop
>> patch 2/3 and apply 1/3 and 3/3.
>>
>> Richard, as I mentioned earlier, perhaps not clearly enough, I think we should
>> put a check in audit_set_loginuid() to skip the (int)-1 value from appearing
>> in session_id during normal operation. In other words, roll/reset the value
>> in session_id one value early so we don't run into problems with the (int)-1
>> unset sentinel value.
>
> I noted your comment earlier and I agree skipping the sentinel is
> required, but if we are rolling this counter, we have bigger issues
> unless there is a way to determine if a sessionID value is still in use
> by at least one task.
The session ID reuse problem is independent of the rollover problem;
the session ID value is going to roll at some point, regardless of if
we skip one value or not. I guess if there is any comfort in the
value rolling, it is only bumped on a new interactive user session and
given that systemd is now taking to killing all user processes on
logout (no more nohup'ing things) it is unlikely that this will be an
issue on a modern Linux system (it would appear that most everyone is
moving to systemd, for better or worse). For those truly paranoid
admins, they don't have to filter on it - problem solved - for
everyone else, it can be a useful tool.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* auditd not triggering ANOM_ROOT_TRANS record
From: teroz @ 2016-10-25 12:09 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 278 bytes --]
I used one of the dirtycow root exploits on Fedora24 configured
with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
best way to trivially audit for a successful privilege escalation?
[-- Attachment #1.2: Type: text/html, Size: 368 bytes --]
[-- Attachment #2: audit.log.excerpt --]
[-- Type: application/octet-stream, Size: 2386 bytes --]
type=USER_ACCT msg=audit(1477392049.316:187): pid=934 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="teroz" exe="/usr/lib/syste
type=CRED_DISP msg=audit(1477391860.052:309): pid=1086 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success'
type=AVC msg=audit(1477391878.107:310): avc: denied { write } for pid=1221 comm="passwd" path="/proc/1215/mem" dev="proc" ino=25986 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=file permissive=0
type=SYSCALL msg=audit(1477391878.107:310): arch=c000003e syscall=59 per=400000 success=yes exit=0 a0=563229803c50 a1=563229803140 a2=563229802540 a3=563229803140 items=1 ppid=1215 pid=1221 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="passwd" exe="/usr/bin/passwd" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null)
type=BPRM_FCAPS msg=audit(1477391878.107:310): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=0000003fffffffff new_pi=0000000000000000 new_pe=0000003fffffffff
type=EXECVE msg=audit(1477391878.107:310): argc=1 a0="/usr/bin/passwd"
type=CWD msg=audit(1477391878.107:310): cwd="/home/teroz"
type=PATH msg=audit(1477391878.107:310): item=0 name="/usr/bin/passwd" inode=275481 dev=fd:00 mode=0104755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:passwd_exec_t:s0 nametype=NORMAL
type=PROCTITLE msg=audit(1477391878.107:310): proctitle="/usr/bin/passwd"
type=AVC msg=audit(1477391878.108:311): avc: denied { read } for pid=1221 comm="bash" name=".bashrc" dev="dm-0" ino=8726369 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1477391878.108:311): arch=c000003e syscall=2 success=no exit=-13 a0=561de422cb40 a1=0 a2=9 a3=561de422ce60 items=1 ppid=1215 pid=1221 auid=1000 uid=0 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="bash" exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null)
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: auditd not triggering ANOM_ROOT_TRANS record
From: William Roberts @ 2016-10-25 13:09 UTC (permalink / raw)
To: teroz; +Cc: linux-audit
In-Reply-To: <CANhT1Hh=J4aA2bm=2YMXVk5_zp9DNcwXx=SPdOTJj=yrEqnjag@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 662 bytes --]
On Oct 25, 2016 05:12, "teroz" <terence.namusonge@gmail.com> wrote:
>
> I used one of the dirtycow root exploits on Fedora24 configured
with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
best way to trivially audit for a successful privilege escalation?
>
I would imagine that if it's hijacking an already root or setuid binary,
you won't see anything. As far as that record goes, I have no idea, I'll
let an auditing expert answer that question.
>
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 991 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: auditd not triggering ANOM_ROOT_TRANS record
From: teroz @ 2016-10-25 13:42 UTC (permalink / raw)
To: William Roberts; +Cc: linux-audit
In-Reply-To: <CAFftDdqGxJ91=adEfx5FtsZmU2ZraFe_vGgx8rabph5GC_fHkA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 871 bytes --]
Hey William
exploit is run as a normal user and privilege escalates to a root shell
On Tue, 25 Oct 2016 at 15:09 William Roberts <bill.c.roberts@gmail.com>
wrote:
> On Oct 25, 2016 05:12, "teroz" <terence.namusonge@gmail.com> wrote:
> >
> > I used one of the dirtycow root exploits on Fedora24 configured
> with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
> didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
> best way to trivially audit for a successful privilege escalation?
> >
>
> I would imagine that if it's hijacking an already root or setuid binary,
> you won't see anything. As far as that record goes, I have no idea, I'll
> let an auditing expert answer that question.
> >
> >
> >
>
>
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
[-- Attachment #1.2: Type: text/html, Size: 1815 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: auditd not triggering ANOM_ROOT_TRANS record
From: William Roberts @ 2016-10-25 13:48 UTC (permalink / raw)
To: teroz; +Cc: linux-audit
In-Reply-To: <CANhT1HjaVgpBn9=NwmLKkb07gym4gJTe0_JMw7OTToDfrxMZAg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1224 bytes --]
On Oct 25, 2016 06:42, "teroz" <terence.namusonge@gmail.com> wrote:
>
> Hey William
> exploit is run as a normal user and privilege escalates to a root shell
>
Look under the covers. Dirty cow allows arbitrary file modification, so
somewhere it's likely executing some setuid root thing that it modifies.
Take a peak with strace.
https://www.google.com/amp/www.theregister.co.uk/AMP/2016/10/21/linux_privilege_escalation_hole/
> On Tue, 25 Oct 2016 at 15:09 William Roberts <bill.c.roberts@gmail.com>
wrote:
>>
>> On Oct 25, 2016 05:12, "teroz" <terence.namusonge@gmail.com> wrote:
>> >
>> > I used one of the dirtycow root exploits on Fedora24 configured
with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
best way to trivially audit for a successful privilege escalation?
>> >
>>
>> I would imagine that if it's hijacking an already root or setuid binary,
you won't see anything. As far as that record goes, I have no idea, I'll
let an auditing expert answer that question.
>> >
>> >
>> >
>>
>>
>> >
>> > --
>> > Linux-audit mailing list
>> > Linux-audit@redhat.com
>> > https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 2006 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: auditd not triggering ANOM_ROOT_TRANS record
From: William Roberts @ 2016-10-25 13:59 UTC (permalink / raw)
To: teroz; +Cc: linux-audit
In-Reply-To: <CAFftDdqQxJOHrAmJdKQYfMDzVJUNTFuczumt7NbVtvPzzAYPMQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --]
On Oct 25, 2016 06:48, "William Roberts" <bill.c.roberts@gmail.com> wrote:
>
> On Oct 25, 2016 06:42, "teroz" <terence.namusonge@gmail.com> wrote:
> >
> > Hey William
> > exploit is run as a normal user and privilege escalates to a root shell
> >
>
> Look under the covers. Dirty cow allows arbitrary file modification, so
somewhere it's likely executing some setuid root thing that it modifies.
Take a peak with strace.
Sorry too early in the morning for me, this doesn't require setuid
modification, just a file owned by root looking at the source:
https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c
>
>
https://www.google.com/amp/www.theregister.co.uk/AMP/2016/10/21/linux_privilege_escalation_hole/
>
> > On Tue, 25 Oct 2016 at 15:09 William Roberts <bill.c.roberts@gmail.com>
wrote:
> >>
> >> On Oct 25, 2016 05:12, "teroz" <terence.namusonge@gmail.com> wrote:
> >> >
> >> > I used one of the dirtycow root exploits on Fedora24 configured
with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
best way to trivially audit for a successful privilege escalation?
> >> >
> >>
> >> I would imagine that if it's hijacking an already root or setuid
binary, you won't see anything. As far as that record goes, I have no idea,
I'll let an auditing expert answer that question.
> >> >
> >> >
> >> >
> >>
> >>
> >> >
> >> > --
> >> > Linux-audit mailing list
> >> > Linux-audit@redhat.com
> >> > https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 2615 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: auditd not triggering ANOM_ROOT_TRANS record
From: William Roberts @ 2016-10-25 14:05 UTC (permalink / raw)
To: teroz; +Cc: linux-audit
In-Reply-To: <CAFftDdqpcXsOYNWxMDXd=nn6o+J+EuxdSK_WQRzaytRy3puYqw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2048 bytes --]
On Oct 25, 2016 06:59, "William Roberts" <bill.c.roberts@gmail.com> wrote:
>
> On Oct 25, 2016 06:48, "William Roberts" <bill.c.roberts@gmail.com> wrote:
> >
> > On Oct 25, 2016 06:42, "teroz" <terence.namusonge@gmail.com> wrote:
> > >
> > > Hey William
> > > exploit is run as a normal user and privilege escalates to a root
shell
> > >
> >
> > Look under the covers. Dirty cow allows arbitrary file modification, so
somewhere it's likely executing some setuid root thing that it modifies.
Take a peak with strace.
>
> Sorry too early in the morning for me, this doesn't require setuid
modification, just a file owned by root looking at the source:
>
> https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c
No, I was right before, the comments t in the header of that is just a
sample run showing write to something that's readonly. You would want to
write to a readonly setuid or something else on the system to get an actual
root UID code execution, like a library loaded into a root process.
I'll shut up now, and go get coffee to be productive.
>
>
> >
> >
https://www.google.com/amp/www.theregister.co.uk/AMP/2016/10/21/linux_privilege_escalation_hole/
> >
> > > On Tue, 25 Oct 2016 at 15:09 William Roberts <bill.c.roberts@gmail.com>
wrote:
> > >>
> > >> On Oct 25, 2016 05:12, "teroz" <terence.namusonge@gmail.com> wrote:
> > >> >
> > >> > I used one of the dirtycow root exploits on Fedora24 configured
with 30-pci-dss-v31.rules. I was expecting an ANOM_ROOT_TRANS record but
didn't get one. What triggers an ANOM_ROOT_TRANS record? What then is the
best way to trivially audit for a successful privilege escalation?
> > >> >
> > >>
> > >> I would imagine that if it's hijacking an already root or setuid
binary, you won't see anything. As far as that record goes, I have no idea,
I'll let an auditing expert answer that question.
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >> >
> > >> > --
> > >> > Linux-audit mailing list
> > >> > Linux-audit@redhat.com
> > >> > https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 3315 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Fwd: Syscalls to use
From: warron.french @ 2016-10-26 20:16 UTC (permalink / raw)
To: Steve Grubb, linux-audit
In-Reply-To: <CAJdJdQkE_TiJNVyecYfCT819gWANDNYQpr3wT0UHs16MQWOd+w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2254 bytes --]
Steve, would you mind giving me a little more guidance on this?
Is there anything more specific you can suggest?
I don't want to provide a false sense of security to my IA people.
--------------------------
Warron French
---------- Forwarded message ----------
From: warron.french <warron.french@gmail.com>
Date: Tue, Oct 11, 2016 at 2:58 PM
Subject: Syscalls to use
To: linux-audit@redhat.com
I apologize, but I am not sure how to go about determining the appropriate
syscalls to use for various audit goals.
I know that recently I learned to use the ausyscall --dump command to list
the ausyscalls; but apparently I mis-understood/interpreted the purpose of
1 or 2 of the syscalls and had to be corrected (thanks Steve).
Anyway, my organization has a goal to audit several things; of which I know
how to manage most, for examples:
1. File & Object
- Creation (Success/Failure) | w
- Access (Success/Failure) | r
- Deletion (Success/Failure) | w
- Content Modification (Success/Failure) | a
- Permission Modification (Success/Failure) | a
- Ownership Modification (Success/Failure) | a
For these I would have used a watch (*-w*) rule and set the -p flags to *r,
w* or *a* as shown above. From what I understand though, correct me if I
am wrong Steve, we should be getting away from the watch rules and move
towards Syscalls and using *-F path=/path/to/file*, or
*-F path=/path/to/several_files/* -- is this correct, both for RHEL6 and
RHEL7?
Also, I need to audit (Success/Failure) for the following sort of things:
*Authentications*
Logons
Logoffs
*Writes/downloads to external devices/media*
*Uploads from external devices/media *(
*such as DvD, thumbdrive, etc)*
*User & Group* *events*
User: Creation, deletion, Modification, suspending/locking
Group/Role: Creation, deletion, modification
*Use of Privileged/Special Rights events* (
*such as sudo, su, etc..)*
*Printing to a print-device*
*Printing to a file*
Thanks in advance for any steering someone could provide to get me moving
in the correct direction.
--------------------------
Warron French
[-- Attachment #1.2: Type: text/html, Size: 4576 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH] audit: less stack usage for /proc/*/loginuid
From: Alexey Dobriyan @ 2016-10-29 16:04 UTC (permalink / raw)
To: paul, eparis; +Cc: linux-audit
%u requires 10 characters at most not 20.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
fs/proc/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1243,7 +1243,7 @@ static const struct file_operations proc_oom_score_adj_operations = {
};
#ifdef CONFIG_AUDITSYSCALL
-#define TMPBUFLEN 21
+#define TMPBUFLEN 11
static ssize_t proc_loginuid_read(struct file * file, char __user * buf,
size_t count, loff_t *ppos)
{
^ permalink raw reply
* ausearch message types
From: LC Bruzenak @ 2016-10-31 23:21 UTC (permalink / raw)
To: linux-audit
I'm on the 2.4.5 version of the audit code.
Has anyone thought about or implemented a exclusionary message list,
such as:
ausearch -m ALL-avc,user_avc -ts today
I'd like to be able to search in this manner, where I exclude certain
message types.
I could write a patch, but if anyone has already done this I'd happily
use theirs.
The message type list is so long that it would be painful to have the
comma-delimited list of all but a couple.
Thx,
LCB
--
LC Bruzenak
magitekltd.com
^ permalink raw reply
* Re: ausearch message types
From: LC Bruzenak @ 2016-10-31 23:37 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5817D1DE.7040909@magitekltd.com>
On 10/31/2016 04:21 PM, LC Bruzenak wrote:
> I'm on the 2.4.5 version of the audit code.
> Has anyone thought about or implemented a exclusionary message list,
> such as:
>
> ausearch -m ALL-avc,user_avc -ts today
Actually in this case I'm running the search from a script so I can
easily take the stderr results from "ausearch -i -m help", pipe them
into a sed substitution which removes the preceding text, removes the
ones I don't want, and replaces the spaces with commas.
So for now I am set; still I think it would perhaps be helpful to have
at some point.
--
LC Bruzenak
magitekltd.com
^ permalink raw reply
* Re: [PATCH] audit: less stack usage for /proc/*/loginuid
From: Richard Guy Briggs @ 2016-11-02 6:10 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-audit
In-Reply-To: <20161029160439.GE1246@avx2>
On 2016-10-29 19:04, Alexey Dobriyan wrote:
> %u requires 10 characters at most not 20.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Ack, looks reasonable to me. This has been there from the original
commit 1e2d1492e178 Serge Hallyn, Feb 2005.
> ---
>
> fs/proc/base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1243,7 +1243,7 @@ static const struct file_operations proc_oom_score_adj_operations = {
> };
>
> #ifdef CONFIG_AUDITSYSCALL
> -#define TMPBUFLEN 21
> +#define TMPBUFLEN 11
> static ssize_t proc_loginuid_read(struct file * file, char __user * buf,
> size_t count, loff_t *ppos)
> {
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH] audit: less stack usage for /proc/*/loginuid
From: Paul Moore @ 2016-11-03 21:28 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-audit
In-Reply-To: <20161029160439.GE1246@avx2>
On Sat, Oct 29, 2016 at 12:04 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> %u requires 10 characters at most not 20.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
>
> fs/proc/base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks reasonable to me, merged. Thanks.
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1243,7 +1243,7 @@ static const struct file_operations proc_oom_score_adj_operations = {
> };
>
> #ifdef CONFIG_AUDITSYSCALL
> -#define TMPBUFLEN 21
> +#define TMPBUFLEN 11
> static ssize_t proc_loginuid_read(struct file * file, char __user * buf,
> size_t count, loff_t *ppos)
> {
--
paul moore
www.paul-moore.com
^ permalink raw reply
* aureport endless loop with specific input on Debian 8
From: Vincas Dargis @ 2016-11-05 13:05 UTC (permalink / raw)
To: linux-audit
Hi,
I have reported bug in Debian bug tracker [1] that after upgrading to Debian 8, aureport does not finish it's
"reporting" for hours one some inputs, generated by ausearch. It's stuck with 100% CPU usage.
Since maintainer haven't responded yet, I though I could try for help directly here.
More info, and two example input files for reproducing attached in same bug report.
I wonder, would it be... "reasonable" to hope for some kind isolated patch that Debian maintainer could apply and
release fix for Debian 8 which is currently in "stable" mode? I know it's kinda not the mailing list to ask about it,
but maybe you have experience in that regard?
Thanks!
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841272
^ permalink raw reply
* Re: aureport endless loop with specific input on Debian 8
From: Steve Grubb @ 2016-11-05 14:37 UTC (permalink / raw)
To: Vincas Dargis; +Cc: linux-audit
In-Reply-To: <4cb61e99-f114-d48a-768f-70e7e1df4331@gmail.com>
On Sat, 5 Nov 2016 15:05:32 +0200
Vincas Dargis <vindrg@gmail.com> wrote:
> I have reported bug in Debian bug tracker [1] that after upgrading to
> Debian 8, aureport does not finish it's "reporting" for hours one
> some inputs, generated by ausearch. It's stuck with 100% CPU usage.
If I read that correctly, this is against audit-2.4. There was linked
list fixes to ausearch/report in 2.4.4. I suspect that fixes your bug
report. Its not reproducible with the latest version.
-Steve
> Since maintainer haven't responded yet, I though I could try for help
> directly here.
>
> More info, and two example input files for reproducing attached in
> same bug report.
>
> I wonder, would it be... "reasonable" to hope for some kind isolated
> patch that Debian maintainer could apply and release fix for Debian 8
> which is currently in "stable" mode? I know it's kinda not the
> mailing list to ask about it, but maybe you have experience in that
> regard?
>
> Thanks!
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841272
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: aureport endless loop with specific input on Debian 8
From: Steve Grubb @ 2016-11-05 17:30 UTC (permalink / raw)
To: Vincas Dargis; +Cc: linux-audit
In-Reply-To: <20161105143702.07cc65e2@ivy-bridge>
On Sat, 5 Nov 2016 14:37:02 +0000
Steve Grubb <sgrubb@redhat.com> wrote:
> On Sat, 5 Nov 2016 15:05:32 +0200
> Vincas Dargis <vindrg@gmail.com> wrote:
> > I have reported bug in Debian bug tracker [1] that after upgrading
> > to Debian 8, aureport does not finish it's "reporting" for hours one
> > some inputs, generated by ausearch. It's stuck with 100% CPU
> > usage.
>
> If I read that correctly, this is against audit-2.4. There was linked
> list fixes to ausearch/report in 2.4.4. I suspect that fixes your bug
> report. Its not reproducible with the latest version.
Pretty sure this is the fix:
https://fedorahosted.org/audit/changeset?format=diff&new=1116&old=1114&new_path=%2Ftrunk&old_path=%2Ftrunk
-Steve
> > Since maintainer haven't responded yet, I though I could try for
> > help directly here.
> >
> > More info, and two example input files for reproducing attached in
> > same bug report.
> >
> > I wonder, would it be... "reasonable" to hope for some kind isolated
> > patch that Debian maintainer could apply and release fix for Debian
> > 8 which is currently in "stable" mode? I know it's kinda not the
> > mailing list to ask about it, but maybe you have experience in that
> > regard?
> >
> > Thanks!
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841272
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: aureport endless loop with specific input on Debian 8
From: Vincas Dargis @ 2016-11-06 10:22 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20161105173020.266f2f02@ivy-bridge>
2016.11.05 19:30, Steve Grubb wrote:
> Pretty sure this is the fix:
> https://fedorahosted.org/audit/changeset?format=diff&new=1116&old=1114&new_path=%2Ftrunk&old_path=%2Ftrunk
Thanks! I'll try to convince maintainer to add this patch.
^ permalink raw reply
* [PATCH] audit: tame initialization warning len_abuf in audit_log_execve_info
From: Richard Guy Briggs @ 2016-11-10 6:39 UTC (permalink / raw)
To: linux-audit, linux-kernel, containers
Cc: Richard Guy Briggs, Eric Paris, Paul Moore, Steve Grubb
Tame initialization warning of len_abuf in audit_log_execve_info even
though there isn't presently a bug introduced by commit 43761473c254
("audit: fix a double fetch in audit_log_single_execve_arg()"). Using
UNINITIALIZED_VAR instead may mask future bugs.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/auditsc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e414dfa..d161b17 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1000,7 +1000,7 @@ static void audit_log_execve_info(struct audit_context *context,
long len_rem;
long len_full;
long len_buf;
- long len_abuf;
+ long len_abuf = 0;
long len_tmp;
bool require_data;
bool encode;
--
1.7.1
^ permalink raw reply related
* [PATCH] audit: skip sessionid sentinel value when auto-incrementing
From: Richard Guy Briggs @ 2016-11-10 6:41 UTC (permalink / raw)
To: linux-audit, linux-kernel, containers
Cc: Richard Guy Briggs, Eric Paris, Paul Moore, Steve Grubb
The value (unsigned int)-1 is used as a sentinel to indicate the
sessionID is unset. Skip this value when the session_id value wraps.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/auditsc.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 5abf1dc..e414dfa 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2025,8 +2025,11 @@ int audit_set_loginuid(kuid_t loginuid)
goto out;
/* are we setting or clearing? */
- if (uid_valid(loginuid))
+ if (uid_valid(loginuid)) {
sessionid = (unsigned int)atomic_inc_return(&session_id);
+ if (unlikely(sessionid == (unsigned int)-1))
+ sessionid = (unsigned int)atomic_inc_return(&session_id);
+ }
task->sessionid = sessionid;
task->loginuid = loginuid;
--
1.7.1
^ permalink raw reply related
* [pcmoore-audit:working-testing 5/6] kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
From: kbuild test robot @ 2016-11-11 21:32 UTC (permalink / raw)
To: Paul Moore; +Cc: XXX, linux-audit, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]
tree: git://git.infradead.org/users/pcmoore/audit working-testing
head: a49c8e50dda0d0232dfbed567608724c9666b6ab
commit: 20fb66989030c8f631d687ddaca75b9f7f2ee589 [5/6] Work in progress, no commit description yet.
config: mips-mtx1_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 20fb66989030c8f631d687ddaca75b9f7f2ee589
# save the attached .config to linux build tree
make.cross ARCH=mips
All error/warnings (new ones prefixed by >>):
In file included from include/linux/file.h:8:0,
from kernel/audit.c:46:
kernel/audit.c: In function 'audit_log_start':
>> kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:518:25: note: in definition of macro '__ACCESS_ONCE'
__maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
^
>> kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
>> kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:518:52: note: in definition of macro '__ACCESS_ONCE'
__maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
^
>> kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
>> kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:519:19: note: in definition of macro '__ACCESS_ONCE'
(volatile typeof(x) *)&(x); })
^
>> kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
>> kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:519:26: note: in definition of macro '__ACCESS_ONCE'
(volatile typeof(x) *)&(x); })
^
>> kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
vim +1457 kernel/audit.c
1451 * 2. current != auditd
1452 * 3. ACCESS_ONCE(audit_cmd_mutex.owner) != current
1453 * 4. ???
1454 */
1455
1456 if ((!audit_pid && audit_pid != current->tgid) &&
> 1457 (ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
1458 long sleep_time = audit_backlog_wait_time;
1459
1460 while (audit_backlog_limit &&
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21844 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [pcmoore-audit:working-testing 5/6] kernel/audit.c:1456:2: note: in expansion of macro 'if'
From: kbuild test robot @ 2016-11-12 0:49 UTC (permalink / raw)
To: Paul Moore; +Cc: XXX, linux-audit, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 11153 bytes --]
tree: git://git.infradead.org/users/pcmoore/audit working-testing
head: a49c8e50dda0d0232dfbed567608724c9666b6ab
commit: 20fb66989030c8f631d687ddaca75b9f7f2ee589 [5/6] Work in progress, no commit description yet.
config: x86_64-randconfig-s2-11120755 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 20fb66989030c8f631d687ddaca75b9f7f2ee589
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/file.h:8:0,
from kernel/audit.c:46:
kernel/audit.c: In function 'audit_log_start':
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^
include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> kernel/audit.c:1456:2: note: in expansion of macro 'if'
if ((!audit_pid && audit_pid != current->tgid) &&
^~
include/linux/compiler.h:520:26: note: in expansion of macro '__ACCESS_ONCE'
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
^~~~~~~~~~~~~
kernel/audit.c:1457:7: note: in expansion of macro 'ACCESS_ONCE'
(ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
^~~~~~~~~~~
vim +/if +1456 kernel/audit.c
1440 struct timespec t;
1441 unsigned int uninitialized_var(serial);
1442
1443 if (audit_initialized != AUDIT_INITIALIZED)
1444 return NULL;
1445
1446 if (unlikely(!audit_filter(type, AUDIT_FILTER_TYPE)))
1447 return NULL;
1448
1449 /* XXX - wait on a possible backlog only under these conditions:
1450 * 1. audit_backlog_limit is non-zero
1451 * 2. current != auditd
1452 * 3. ACCESS_ONCE(audit_cmd_mutex.owner) != current
1453 * 4. ???
1454 */
1455
> 1456 if ((!audit_pid && audit_pid != current->tgid) &&
1457 (ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
1458 long sleep_time = audit_backlog_wait_time;
1459
1460 while (audit_backlog_limit &&
1461 (skb_queue_len(&audit_queue) > audit_backlog_limit)) {
1462 /* wake kauditd to try and flush the queue */
1463 wake_up_interruptible(&kauditd_wait);
1464
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27929 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [pcmoore-audit:working-testing 5/6] kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
From: Paul Moore @ 2016-11-12 1:29 UTC (permalink / raw)
To: kbuild test robot; +Cc: XXX, linux-audit, kbuild-all
In-Reply-To: <201611120519.I6aVcDJZ%fengguang.wu@intel.com>
On Fri, Nov 11, 2016 at 4:32 PM, kbuild test robot
<fengguang.wu@intel.com> wrote:
> tree: git://git.infradead.org/users/pcmoore/audit working-testing
> head: a49c8e50dda0d0232dfbed567608724c9666b6ab
> commit: 20fb66989030c8f631d687ddaca75b9f7f2ee589 [5/6] Work in progress, no commit description yet.
> config: mips-mtx1_defconfig (attached as .config)
> compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 20fb66989030c8f631d687ddaca75b9f7f2ee589
> # save the attached .config to linux build tree
> make.cross ARCH=mips
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/linux/file.h:8:0,
> from kernel/audit.c:46:
> kernel/audit.c: In function 'audit_log_start':
>>> kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
> (ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
Sorry for the noise folks, I wasn't aware the kbuiler robot was
watching this branch/repo. I'll try to move my testing patches to a
new repo soon to avoid things like this.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [pcmoore-audit:working-testing 5/6] kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
From: Fengguang Wu @ 2016-11-14 0:26 UTC (permalink / raw)
To: Paul Moore; +Cc: XXX, linux-audit, kbuild-all
In-Reply-To: <CAHC9VhSRKSq_LSxY3QJ02BzUY6+83Ak18k5AUivv72i4GhjGow@mail.gmail.com>
Hi Paul,
On Fri, Nov 11, 2016 at 08:29:36PM -0500, Paul Moore wrote:
>On Fri, Nov 11, 2016 at 4:32 PM, kbuild test robot
><fengguang.wu@intel.com> wrote:
>> tree: git://git.infradead.org/users/pcmoore/audit working-testing
>> head: a49c8e50dda0d0232dfbed567608724c9666b6ab
>> commit: 20fb66989030c8f631d687ddaca75b9f7f2ee589 [5/6] Work in progress, no commit description yet.
>> config: mips-mtx1_defconfig (attached as .config)
>> compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
>> reproduce:
>> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout 20fb66989030c8f631d687ddaca75b9f7f2ee589
>> # save the attached .config to linux build tree
>> make.cross ARCH=mips
>>
>> All error/warnings (new ones prefixed by >>):
>>
>> In file included from include/linux/file.h:8:0,
>> from kernel/audit.c:46:
>> kernel/audit.c: In function 'audit_log_start':
>>>> kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
>> (ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
>
>Sorry for the noise folks, I wasn't aware the kbuiler robot was
>watching this branch/repo. I'll try to move my testing patches to a
>new repo soon to avoid things like this.
I'm sorry too. The other way is for the robot to only send private
reports to the committer (ie. you) for the 'working-testing' branch.
Paul, would you like me to set it up like that?
Thanks,
Fengguang
^ permalink raw reply
* Re: [pcmoore-audit:working-testing 5/6] kernel/audit.c:1457:34: error: 'struct mutex' has no member named 'owner'
From: Paul Moore @ 2016-11-14 15:12 UTC (permalink / raw)
To: Fengguang Wu; +Cc: XXX, linux-audit, kbuild-all
In-Reply-To: <20161114002638.3asa6fkzcggievjs@wfg-t540p.sh.intel.com>
On Sun, Nov 13, 2016 at 7:26 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> Hi Paul,
>
> On Fri, Nov 11, 2016 at 08:29:36PM -0500, Paul Moore wrote:
>>
>> On Fri, Nov 11, 2016 at 4:32 PM, kbuild test robot
>> <fengguang.wu@intel.com> wrote:
>>>
>>> tree: git://git.infradead.org/users/pcmoore/audit working-testing
>>> head: a49c8e50dda0d0232dfbed567608724c9666b6ab
>>> commit: 20fb66989030c8f631d687ddaca75b9f7f2ee589 [5/6] Work in progress,
>>> no commit description yet.
>>> config: mips-mtx1_defconfig (attached as .config)
>>> compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
>>> reproduce:
>>> wget
>>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>>> -O ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> git checkout 20fb66989030c8f631d687ddaca75b9f7f2ee589
>>> # save the attached .config to linux build tree
>>> make.cross ARCH=mips
>>>
>>> All error/warnings (new ones prefixed by >>):
>>>
>>> In file included from include/linux/file.h:8:0,
>>> from kernel/audit.c:46:
>>> kernel/audit.c: In function 'audit_log_start':
>>>>>
>>>>> kernel/audit.c:1457:34: error: 'struct mutex' has no member named
>>>>> 'owner'
>>>
>>> (ACCESS_ONCE(audit_cmd_mutex.owner) != current)) {
>>
>>
>> Sorry for the noise folks, I wasn't aware the kbuiler robot was
>> watching this branch/repo. I'll try to move my testing patches to a
>> new repo soon to avoid things like this.
>
> I'm sorry too. The other way is for the robot to only send private
> reports to the committer (ie. you) for the 'working-testing' branch.
> Paul, would you like me to set it up like that?
As long as it is the committer and not the patch author, I think that
would be okay. Would it be possible to do the same for all branches
other than 'next' and 'stable-*'?
If you are tracking the SELinux repository, you could do the same for that repo.
--
paul moore
www.paul-moore.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox