| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAPr7RtVSojwe5Q9k=EE6SSUAE1a46beqOV0TCZbkfhvrADQEGg@mail.gmail.com>
Date: Mon, 29 Dec 2014 13:06:54 +0800
From: ivo welch <ivo.welch@...il.com>
To: Eric Paris <eparis@...hat.com>
Cc: Heinrich Schuchardt <xypron.glpk@....de>,
linux-kernel@...r.kernel.org
Subject: Re: fanotify bug on gdb -- hard crash
thank you, eric. will do. I read up on it above and now understand it better.
the example in the man page seems somewhat misfortunate. I would use
an example that does not, by default, lock up the user system.
(perhaps add a second example with the _PERM feature that shows how it
responds.)
regards,
/iaw
----
Ivo Welch (ivo.welch@...il.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
Director, UCLA Anderson Fink Center for Finance and Investments
Free Finance Textbook, http://book.ivo-welch.info/
Editor, Critical Finance Review, http://www.critical-finance-review.org/
On Mon, Dec 29, 2014 at 12:29 PM, Eric Paris <eparis@...hat.com> wrote:
> Change FAN_OPEN_PERM to FAN_OPEN
>
> If you have any more deadlocks, please let us know. Once you understand
> the difference between the two let us know if there are any more
> problems...
>
> -Eric
>
> On Mon, 2014-12-29 at 08:13 +0800, ivo welch wrote:
>>
>>
>> I really don't know what I am doing. however, the code is really not
>> mine, but verbatim from the man-page example,
>> http://man7.org/linux/man-pages/man7/fanotify.7.html . I had more
>> code below my code, but had whittled down the example to illustrate
>> where my system locks up.
>>
>>
>> I wonder if there could be safeguards in the call to avoid crashing
>> the system. I know fanotify is playing with fire, but should it
>> incapacitate the system in this way?
>>
>>
>> in the end, all I want to do is log each and every file-open operation
>> asap. I want to do read-only probing. could someone please point me
>> to a correct example or facility if the manpage is wrong.
>>
>>
>> /iaw
>>
>>
>>
>> ----
>> Ivo Welch (ivo.welch@...il.com)
>> http://www.ivo-welch.info/
>> J. Fred Weston Professor of Finance
>> Anderson School at UCLA, C519
>> Director, UCLA Anderson Fink Center for Finance and Investments
>> Free Finance Textbook, http://book.ivo-welch.info/
>> Editor, Critical Finance Review,
>> http://www.critical-finance-review.org/
>>
>>
>> On Mon, Dec 29, 2014 at 7:13 AM, Eric Paris <eparis@...hat.com> wrote:
>> Why are you setting FAN_OPEN_PERM and then not responding to
>> perm
>> requests? Of course the system is going to appear locked,
>> until you
>> start responding to open events, remove that mark, or close
>> the fanotify
>> fd...
>>
>> -Eric
>>
>> On Fri, 2014-12-26 at 19:40 +0100, Heinrich Schuchardt wrote:
>> > Hello Ivo,
>> >
>> > On 26.12.2014 15:45, ivo welch wrote:
>> > > I am not a kernel developer, so forgive the intrusion.
>> > >
>> > > I suspect I have found either a bug in gdb (less likely)
>> or a bug in
>> > > fanotify (more likely). it is replicable, and the code is
>> almost
>> > > unchanged from the example in the fanotify man page. to
>> trigger it,
>> > > all an su needs to do is to step through the program below
>> with gdb
>> > > 7.8.1 'n' command, and linux locks up the system pretty
>> hard (reboot
>> > > required). I have confirmed the replicability of this
>> issue on a
>> > > clean arch 2014.12.01 3.17.6-1 system and on a clean
>> ubuntu 14.10
>> > > system, both VMs created just to check it. /iaw
>> > >
>> > >
>> > > #define _GNU_SOURCE /* Needed to get O_LARGEFILE
>> definition */
>> > > #include <stdio.h>
>> > > #include <stdlib.h>
>> > > #include <errno.h>
>> > > #include <fcntl.h>
>> > > #include <poll.h>
>> > > #include <sys/fanotify.h>
>> > >
>> > > int main(int argc, char *argv[]) {
>> > > int fd;
>> > > fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT |
>> FAN_NONBLOCK,
>> > > O_RDONLY | O_LARGEFILE);
>> > > if (fd == -1) exit(1);
>> > > fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
>> > > if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
>> FAN_OPEN_PERM |
>> > > FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
>> > > fprintf(stderr, "in gdb step through with 'n' for
>> repeat.\n");
>> > > fprintf(stderr, " (and sometimes otherwise), a ^C
>> works, but a ^Z
>> > > and then ^C does not.\n");
>> > > }
>> >
>> > I was not able to reproduce your problem according to your
>> description
>> > with Ubuntu 14.10.
>> >
>> > I ran a Ubuntu 14.04 amd64 LiveImage in a VM and compiled
>> your example with
>> > gcc -g -o test test.c
>> >
>> > The gdb version in Ubuntu 14.10 is 7.4 and not 7.8.1. The
>> kernel version
>> > is 3.13.
>> >
>> > root@...ntu:/home/ubuntu/temp# gdb ./test
>> > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
>> > Copyright (C) 2012 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later
>> > <http://gnu.org/licenses/gpl.html>
>> > This is free software: you are free to change and
>> redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law. Type
>> "show copying"
>> > and "show warranty" for details.
>> > This GDB was configured as "x86_64-linux-gnu".
>> > For bug reporting instructions, please see:
>> > <http://bugs.launchpad.net/gdb-linaro/>...
>> > Reading symbols from /home/ubuntu/temp/test...done.
>> > (gdb) break main
>> > Breakpoint 1 at 0x400693: file test.c, line 10.
>> > (gdb) run
>> > Starting program: /home/ubuntu/temp/test
>> > warning: no loadable sections found in added symbol-file
>> system-supplied
>> > DSO at 0x7ffff7ffa000
>> >
>> > Breakpoint 1, main (argc=1, argv=0x7fffffffe638) at
>> test.c:10
>> > 10 fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT
>> | FAN_NONBLOCK,
>> > (gdb) n
>> > 12 if (fd == -1) exit(1);
>> > (gdb) n
>> > 13 fprintf(stderr, "calling fanotify_mark: fd=%d\n",
>> fd);
>> > (gdb) n
>> > calling fanotify_mark: fd=7
>> > 14 if (fanotify_mark(fd, FAN_MARK_ADD |
>> FAN_MARK_MOUNT,
>> > FAN_OPEN_PERM |
>> > (gdb) n
>> > 16 fprintf(stderr, "in gdb step through with 'n' for
>> repeat.\n");
>> > (gdb) n
>> > in gdb step through with 'n' for repeat.
>> > 17 fprintf(stderr, " (and sometimes otherwise), a ^C
>> works, but
>> > a ^Z and then ^C does not.\n");
>> > (gdb) n
>> > (and sometimes otherwise), a ^C works, but a ^Z and then
>> ^C does not.
>> > 18 }
>> > (gdb) n
>> > 0x00007ffff7a3b78d in __libc_start_main () from
>> > /lib/x86_64-linux-gnu/libc.so.6
>> > (gdb) n
>> > Single stepping until exit from function __libc_start_main,
>> > which has no line number information.
>> > [Inferior 1 (process 4423) exited with code 0110]
>> > (gdb) n
>> > The program is not being run.
>> > (gdb) q
>> > root@...ntu:/home/ubuntu/temp#
>> >
>> > >
>> > > I don't know who else to tell this. I hope this report is
>> useful, if
>> > > someone competent can confirm it. /iaw
>> >
>> > Bug reports for the Linux kernel should be adressed to the
>> maintainer.
>> > You can find him in the MAINTAINERS file of the linux
>> source.
>> >
>> > See
>> >
>> https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
>> > https://bugzilla.kernel.org/
>> >
>> > Before reporting a bug it is worthwhile to check if the
>> problem also
>> > occurs with the current kernel version (as of today 3.18.1
>> or 3.19-rc1).
>> >
>> > > PS: Is there an alternative to fanotify to avoid this? I
>> want to
>> > > learn of all file-open requests on a ro device.
>> > > ----
>> >
>> > The fanotify API is the right choice. Inotify is an
>> alternative but
>> > requires marking all directories.
>> >
>> > For your task you can use the code provided at
>> > https://launchpad.net/fatrace
>> >
>> > Best regards
>> >
>> > Heinrich Schuchardt
>>
>>
>>
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists