3

I want to make use of fanotify(7) and the problem I run into is that on some kernels CONFIG_FANOTIFY_ACCESS_PERMISSIONS does not work, although CONFIG_FANOTIFY is configured.

At the very least I'd like to report this condition.

Now on Debian and Ubuntu I could use the equivalent of grep CONFIG_FANOTIFY_ACCESS_PERMISSIONS /boot/config-$(uname -r) to verify that the feature is available. On some other systems I could use the equivalent of zgrep CONFIG_FANOTIFY_ACCESS_PERMISSIONS /proc/config.gz, but there are probably some more systems that are not covered by these two methods.

Is there a way to figure out in any of the fanotify(7) functions whether or not fanotify permission handling is available on the kernel currently running?

I was thinking of a method similar to the returned ENOSYS when fanotify_mark() is not implemented (fanotify_mark(2)), but could not find anything like that in the documentation.

0xC0000022L
  • 20,597
  • 9
  • 86
  • 152

1 Answers1

3

It seems that fanotify_mark() returns EINVAL when FAN_ALL_PERM_EVENTS is passed but CONFIG_FANOTIFY_ACCESS_PERMISSIONS is disabled.

See fs/notify/fanotify/fanotify_user.c in kernel sources:

SYSCALL_DEFINE5(fanotify_mark, int, fanotify_fd, unsigned int, flags,
                              __u64, mask, int, dfd,
                              const char  __user *, pathname)
{
...

#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
        if (mask & ~(FAN_ALL_EVENTS | FAN_ALL_PERM_EVENTS | FAN_EVENT_ON_CHILD))
#else
        if (mask & ~(FAN_ALL_EVENTS | FAN_EVENT_ON_CHILD))
#endif
                return -EINVAL;
gavv
  • 4,649
  • 1
  • 23
  • 40
  • Good find. That would be e.g. `fanotify_mark(-1, FAN_MARK_FLUSH, FAN_ALL_PERM_EVENTS, -1, NULL)` C library call yielding -1 with `errno == ENOSYS` if no fanotify support, `errno == EINVAL` if no access permissions event support, and `errno == EBADF` if fanotify support with access permissions support was available. But, can you rely on such undocumented behaviour? Is it likely to change in the future? I do not know; I myself probably would not trust this. It might be worth a query at linux-fsdevel mailing list, though. – Nominal Animal Jan 13 '16 at 12:47
  • @NominalAnimal, yeah, totally undocumented, but I see no reasons why this check may be removed in future; it's logical to check if user's request is supported. – gavv Jan 13 '16 at 12:56
  • I'm more worried about the checks being reordered at some point, actually. There are many ways the various checks [in that function](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/notify/fanotify/fanotify_user.c) could be reordered that would disable the detection. For example, if the file descriptor was checked prior to the mask check. – Nominal Animal Jan 13 '16 at 13:30
  • 2
    D'oh! I'm an idiot. If you make sure the fanotify mark is otherwise proper and correct -- instead of using the stupid will-always-fail check in my comment above --, then there is no risk, as the only reason such a mark would fail is because of lack of support. In short: just make sure the `fanotify_mark()` call is doing a valid operation, with at least some of `FAN_ALL_PERM_EVENTS` in the mask. – Nominal Animal Jan 13 '16 at 13:37