All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
To: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH 0/1] Manpages for the fanotify API: FAN_ACCESS_PERM for readdir
Date: Mon, 07 Apr 2014 20:16:27 +0200	[thread overview]
Message-ID: <5342EB7B.4010201@gmx.de> (raw)
In-Reply-To: <20140407085624.GB14927-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org>

Hello Jan,

> > FAN_ACCESS_PERM
> > The name is misleading. The permission check is done before executing a file
> > or listing a directory.
>   AFAIK it doesn't happen before listing a directory. But if you are
> convinced it does, I can check more carefully ;)

iterate_dir calls
security_file_permission(file, MAY_READ);
which in turn calls
fsnotify_perm(file, mask);
Which has these lines:
  51         else if (mask & MAY_READ)
  52                 fsnotify_mask = FS_ACCESS_PERM;

This is the result I get for
#include <stdlib.h>
#include <sys/types.h>
#include <dirent.h>
#include <libgen.h>
int main() {
     DIR *dir;
     struct dirent *dp;
     if ((dir = opendir ("/home/test")) == NULL) {
         exit (1);
     }
     while ((dp = readdir (dir)) != NULL) {
         }
         closedir(dir);
         return 0;
}

FAN_OPEN: File /home/test
FAN_ACCESS_PERM: File /home/test
FAN_ACCESS_PERM: File /home/test

I guess it is somewhat inconsistent that
readdir results in FAN_ACCESS_PERM while
read results in FAN_ACCESS_PERM and FAN_ACCESS.

===

This is the result I get for executing
/home/test/test
which contains the following lines
!#/bin/sh
echo Hello world

FAN_OPEN: File /home/test/test
FAN_ACCESS_PERM: File /home/test/test
FAN_ACCESS: File /home/test/test
FAN_OPEN: File /home/test/test
FAN_ACCESS_PERM: File /home/test/test
FAN_ACCESS: File /home/test/test
FAN_ACCESS_PERM: File /home/test/test

The last FAN_ACCESS_PERM probably does not relate to a read() as it is 
not followed by FAN_ACCESS.

===

When running
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
     int fd;
     char buf[4096];
     ssize_t len;
     fd = open("/home/test/test", O_RDONLY);
     len = read(fd, buf, 4096);
     buf[len] = '\0';
     printf("Bytes read %d\n%s\n", len, buf);
     close(fd);
     return 0;
}

I get

FAN_OPEN: File /home/test/test
FAN_ACCESS_PERM: File /home/test/test
FAN_ACCESS: File /home/test/test

When running
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
         int fd;
         char buf[4096];
         ssize_t len;
     fd = open("/home/test/test", O_WRONLY);
     len = write(fd, "visited" , 4);
         close(fd);
         return 0;
}

I get

FAN_OPEN: File /home/test/test
FAN_MODIFY: File /home/test/test

You only receive a permission event before reading and not before writing.

The fanotify API was meant for use in a hierarchical storage management 
system. Should it not be able to inhibit writing, e.g. if the remote 
file is on a read-only medium?

I guess it would make sense to add a FAN_MODIFY_PERM event.

Best regards

Heinrich Schuchardt


--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-04-07 18:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 19:53 [PATCH 1/1] Man pages for the fanotify API xypron.glpk-Mmb7MZpHnFY
     [not found] ` <1393444390-16012-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-03-14 16:42   ` Michael Kerrisk (man-pages)
     [not found]     ` <53233160.9000106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-16 15:32       ` xypron.glpk-Mmb7MZpHnFY
     [not found]         ` <1394983959-5392-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-03-17 15:45           ` Michael Kerrisk (man-pages)
     [not found]             ` <53271880.4090100-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-22 16:42               ` xypron.glpk-Mmb7MZpHnFY
     [not found]                 ` <1395506528-10026-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-03-24 21:23                   ` Michael Kerrisk (man-pages)
     [not found]                     ` <5330A257.9080100-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-25 15:39                       ` Man pages for the fanotify API: merging of events Heinrich Schuchardt
     [not found]                         ` <5331A343.9070403-Mmb7MZpHnFY@public.gmane.org>
2014-03-25 16:37                           ` Jan Kara
2014-03-26 19:09                       ` [PATCH 1/1] Man pages for the fanotify API Eric Paris
2014-04-06  0:01                       ` [PATCH 0/1] Manpages " xypron.glpk-Mmb7MZpHnFY
     [not found]                         ` <1396742468-4752-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-04-06 12:18                           ` Michael Kerrisk (man-pages)
     [not found]                             ` <5341461A.3090405-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-07  8:48                               ` Jan Kara
2014-04-13 14:05                               ` fanotify API: FMODE_NONOTIFY, FMODE_EXEC, FMODE_NOCMTIME Heinrich Schuchardt
2014-04-20 11:56                               ` [PATCH 1/1] Manpages for the fanotify API Heinrich Schuchardt
     [not found]                                 ` <1397994990-9068-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-04-22 14:29                                   ` Michael Kerrisk (man-pages)
     [not found]                                     ` <53567CC2.6050708-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-23 17:40                                       ` [PATCH 1/1] fanotify: add manpages Heinrich Schuchardt
     [not found]                                         ` <1398274809-6107-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-04-23 20:24                                           ` [PATCH] fanotify: add man pages Heinrich Schuchardt
     [not found]                                             ` <1398284672-7410-1-git-send-email-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
2014-04-24 16:25                                               ` Michael Kerrisk (man-pages)
2014-04-07  8:56                           ` [PATCH 0/1] Manpages for the fanotify API Jan Kara
     [not found]                             ` <20140407085624.GB14927-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org>
2014-04-07 18:16                               ` Heinrich Schuchardt [this message]
     [not found]                                 ` <5342EB7B.4010201-Mmb7MZpHnFY@public.gmane.org>
2014-04-07 20:13                                   ` [PATCH 0/1] Manpages for the fanotify API: FAN_ACCESS_PERM for readdir Jan Kara
2014-04-06  0:01                       ` [PATCH 1/1] Manpages for the fanotify API xypron.glpk-Mmb7MZpHnFY

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=5342EB7B.4010201@gmx.de \
    --to=xypron.glpk-mmb7mzphnfy@public.gmane.org \
    --cc=eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=jack-AlSwsSmVLrQ@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.