linux-kernel - Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ba89cc20-ac0c-cf13-9953-5d5546aab6de@samba.org>
Date:   Wed, 19 Feb 2020 11:23:54 +0100
From:   Stefan Metzmacher <metze@...ba.org>
To:     David Howells <dhowells@...hat.com>, viro@...iv.linux.org.uk
Cc:     raven@...maw.net, mszeredi@...hat.com, christian@...uner.io,
        linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver
 #16]

Hi David,

I have a few generic remarks for new syscalls...

>  (3) New single-bit capability flags can be added.  This is a structure-typed
>      attribute and, as such, (2) applies.  Any bits you wanted but the kernel
>      doesn't support are automatically set to 0.
> 
> fsinfo() may be called like the following, for example:
> 
> 	struct fsinfo_params params = {
> 		.at_flags	= AT_SYMLINK_NOFOLLOW,

Shouldn't all new syscalls be able to provide the RESOLVE_

Shouldn't all new syscalls be able to provide the RESOLVE_ flags
supported in openat2?

> 		.flags		= FSINFO_FLAGS_QUERY_PATH,
> 		.request	= FSINFO_ATTR_AFS_SERVER_ADDRESSES,
> 		.Nth		= 2,
> 	};
> 	struct fsinfo_server_address address;
> 	len = fsinfo(AT_FDCWD, "/afs/grand.central.org/doc", &params,
> 		     &address, sizeof(address));

Also passing sizeof(params) would allow future updates of fsinfo_params,
also similar to openat2(), clone3()...

> ========================
> FILESYSTEM NOTIFICATIONS
> ========================
> 
> The second system call, watch_mount(), places a watch on a point in the
> mount topology specified by the dirfd, path and at_flags parameters.  All
> mount topology change and mount attribute change notifications in the
> subtree rooted at that point can be intercepted by the watch.  Watches are
> ducted through pipes:
> 
> 	int fd[2];
> 	pipe2(fd, O_NOTIFICATION_PIPE);
> 	ioctl(fd[0], IOC_WATCH_QUEUE_SET_SIZE, BUF_SIZE);
> 	watch_mount(AT_FDCWD, "/", 0, fd[0], 0x02);

I guess similar things apply here.

Does that make sense to you?

metze




Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)