https://bugzilla.novell.com/show_bug.cgi?id=349942 User suse-beta@cboltz.de added comment https://bugzilla.novell.com/show_bug.cgi?id=349942#c1 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |suse-beta@cboltz.de Status|NEW |NEEDINFO Info Provider| |robin.listas@telefonica.net --- Comment #1 from Christian Boltz 2007-12-23 14:05:28 MST --- Please rename /var/log/audit/audit.log to something else and restart auditd ("rcauditd restart"). Then run the YaST module again. The needed information depends on the behaviour you see: a) If the YaST module crashes again, please attach the y2logs (as described on http://en.opensuse.org/Bugs/YaST). Please also run "aa-logprof" in a xterm and attach the output. b) If moving away the logfile solves the problem, please attach the logfile you moved away. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=349942 User robin.listas@telefonica.net added comment https://bugzilla.novell.com/show_bug.cgi?id=349942#c3 --- Comment #3 from Carlos Robinson 2007-12-23 17:03:06 MST --- Created an attachment (id=188635) --> (https://bugzilla.novell.com/attachment.cgi?id=188635) audit log requested -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=349942 User robin.listas@telefonica.net added comment https://bugzilla.novell.com/show_bug.cgi?id=349942#c4 --- Comment #4 from Carlos Robinson 2008-01-23 17:24:40 MST --- **** Summary:

From a conversation in , where I asked how to manually change the profile to avoid this problem (it happened another time, log to be added later), John Johansen told me of his progress with this bug, and mentioned that it could be triggered after a lazy umount.

At the same time, I learned how to convert audit log timestamps to a human readable format, which suddenly made me realize that I had indeed used "lazy umount" at the time of the audit log entry, in the course of investigating Bug 345039 (comment number 5 there). It is thus possible that this bug is related to Bug 345039 somehow. **** Detailed info. I'll copy the email where we discovered this: +++ The Saturday 2008-01-19 at 15:00 -0800, John Johansen wrote:

Carlos E. R. wrote:

...

Hi,

In the audit log I see this message, repeated several times:

DENIED msg=audit(1199356965.768:7): type=1503 operation="inode_permission" requested_mask="r" denied_mask="mrwiuplk" pid=4946 profile="/usr/sbin/nscd"

This message causes the yast apparmour wizard to crash, with "unknown mask mrwiuplk". This has been reported as Bug 349942 to bugzilla, and I hope will be solved one of these months :-)

well yes hopefully. I am sorry to say I am way behind on my bugzilla but this is a new one to me as it hit someone else. Sadly it is multiple bugs in one. The kernel shouldn't be reporting "mrwiuplk", and the wizard shouldn't be crashing on unknown input.

Ah!

The kernel bug causing this has been fixed but I need to submit it so it can be rolled out for and be made available in an update.

...

What I want to ask here is how should I change the "/usr/sbin/nscd" profile so that the message doesn't pop (and the permission is granted, obviously). As the wizard can't handle it, I don't see how to add that permission easily.

Ugh, well I can tell you permission you want is "r", the problem is I can't tell you what to add. Notice this audit message is missing a name component. That is because the name lookup failed, and the kernel side portion of the bug was with reporting a failed name lookup. Either the pathname was to long, your machine is/was really tight on memory and couldn't allocate a buffer for the pathname or it was lazily unmounted in a race window making it impossible to retrieve the path.

I see it is more complex than I thought. Lazy umount...? Rings a bell. I'll explain below.

I am going to bet it wasn't running out of memory because you would have seen many other problems if the kernel had run out of memory.

1 GiB, and 12GiB swap, desktop use... not likely.

That either leaves the path being to long, the default is 2*PATH_MAX so about a 2k long path. From an unconfined root shell you can change the apparmor maxpath name size to 4K (or any larger value) by doing

echo 4096 > /sys/module/apparmor/parameters/path_max

nimrodel:~ # cat /sys/module/apparmor/parameters/path_max 8192 So it is currently larger.

If this is a reoccuring problem my bet would be its a really long path other wise you are dealing with something that was lazily unmounted, and that is feature yet to be implemented.

A recursive path? It happened only two times as far as I know (I can't read the time stamps - no, now I know).

...

On a side question: How do I translate the date-stamp 1199356965.768 to some thing intelligible by humans? So that I can correlate the log entry to the rest of the system logs.

its unix epoche time and you can use a web site http://www.epochconverter.com/

which gives GMT: Thu, 03 Jan 2008 10:42:45 GMT Your timezone: Thu 03 Jan 2008 02:42:45 AM PST

I got an answer on the Spanish list: cer@nimrodel:~> date --date="@1199356965.768" Thu Jan 3 11:42:45 CET 2008 Knowing the date I may remember what I was doing at the time. And the bell is because I did have used "lazy umount" while working on a bug report of a filesystem crash while writing large files to an encripted partition (Bug 345039). Looking at the dates of the reports: 680 08-01-02 15:20 + 681 08-01-03 04:12 <== + 682 08-01-03 04:26 I see they are close to the date of the apparmour entry... Ok, seeing my notes I did that testing on "Jan 3 11:08:28". On the log I see I rebooted (it crashed) at 11:48:14. The audit log go from "11:42:45" to 11:45:15... it matches very closely: Jan 3 11:40:24 nimrodel smartd[5147]: Device: /dev/hdb, SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 58 to 59 Jan 3 11:40:24 nimrodel smartd[5147]: Device: /dev/hdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 25 to 26 Jan 3 11:40:24 nimrodel smartd[5147]: Device: /dev/hdd, SMART Usage Attribute: 194 Temperature_Celsius changed from 32 to 33 Jan 3 11:42:01 nimrodel /usr/sbin/gpm[3871]: O0o.oops(): [gpm.c(157)]: Jan 3 11:42:01 nimrodel /usr/sbin/gpm[3871]: Opening console failed. Jan 3 11:45:01 nimrodel /usr/sbin/cron[7242]: User not known to the underlying authentication module Jan 3 11:45:01 nimrodel /usr/sbin/cron[7243]: User not known to the underlying authentication module Jan 3 11:48:14 nimrodel syslog-ng[3698]: syslog-ng version 1.6.12 starting ¡BINGO! Whatever this leads to... how curious, it relates to another bug... Do you want me to add this info to the bugzilla? See? If the audit log had used plain date stamps, I might have noticed the coincidence earlier :-P Your mention of "lazy umount" clinched it, because that's the only circumstance in which I use it (see Bug 345039). Now I perhaps should try to recreate that situation with apparmour dissabled... Wow! I hope this is not a simple coincidence! ++- John replied that yes,, I should add this to the Bugzilla, so here it is - I hope it helps:-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=349942 User robin.listas@telefonica.net added comment https://bugzilla.novell.com/show_bug.cgi?id=349942#c6 --- Comment #6 from Carlos Robinson 2008-01-23 17:36:00 MST --- Sorry, I forgot to say the attachment of #5 is an “audit log”. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=349942 User jjohansen@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=349942#c8 John Johansen changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jjohansen@novell.com AssignedTo|kmachalkova@novell.com |jjohansen@novell.com Status|NEEDINFO |ASSIGNED Info Provider|jjohansen@novell.com | --- Comment #8 from John Johansen 2008-01-31 00:43:44 MST --- Well it would be nice if the YaST module didn't crash, but it is not just the YaST module that is crashing. The command line tools don't handle it correctly either. Once the backend dies the YaST module can't recover the lost state so all it can do is pop up a message that there was a bad log message. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.