linux-kernel - Re: [take 3] Use pid in inotify events.

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Nov 2008 09:43:41 -0500
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Evgeniy Polyakov" <zbr@...emap.net>
Cc:	"Christoph Hellwig" <hch@....de>, "Robert Love" <rlove@...ve.org>,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>, john@...nmccutchan.com
Subject: Re: [take 3] Use pid in inotify events.

[RESENT, because LKML bounced some HTML that accidentally got put in the mail.]
[CC+=John McCutchan, this time with hopefully a live email address;
John, some context here: http://marc.info/?t=122633022400003&r=1&w=2 ]

Evgeniy,

On Wed, Nov 19, 2008 at 9:05 AM, Evgeniy Polyakov <zbr@...emap.net> wrote:
>
> Hi Christoph.
>
> On Tue, Nov 18, 2008 at 02:19:37PM +0100, Christoph Hellwig (hch@....de) wrote:
> > Yes, this kind of thing should be enable using an flag to inotify1, and
> > be consistant even for rename.  Doing it as a flag to inotify1 also has
> > the advantage to be able to return an -EPERM when the feature is
> > requested but not allowed instead of letting applications that assume it
> > silently fail.
>
> So effectively you propose to have second generation of the inotify
> which will have additional pid field, which will be unused by all but
> the same uid events?

I suspect that Christoph wants the same thing as I do: some thinking
towards a future-proof design, rather than a quick hack to address the
needs of a single application.

> If you want to return -EPERM, than it will be _always_ returned for non
> sysadmin capable user, which effectively makes it unusable.

Again, appropriate flags in inotify_init1() could fix this -- e.g.,
only fill the field (and give an error if no perms) if a flag is set.

I think what is really needed at this point is some consideration of
what other extensions (if any) might be desired for inotify, and how
we might be best create a design that suits those and future needs.

Cheers,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
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/