Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

On May 16, 2019 10:23:31 PM GMT+02:00, "Dmitry V. Levin" [off-list ref] wrote:

[looks like linux-abi is a typo, Cc'ed linux-api instead]

On Thu, May 16, 2019 at 05:50:22PM +0100, Al Viro wrote:

quoted

[linux-abi cc'd]

On Thu, May 16, 2019 at 06:31:52PM +0200, Christian Brauner wrote:

quoted

On Thu, May 16, 2019 at 05:22:59PM +0100, Al Viro wrote:

quoted

On Thu, May 16, 2019 at 12:52:04PM +0100, David Howells wrote:

quoted

Hi Linus, Al,

Here are some patches that make changes to the mount API UAPI

and two of

quoted

quoted

quoted

quoted

them really need applying, before -rc1 - if they're going to be

applied at

quoted

quoted

quoted

quoted

all.

I'm fine with 2--4, but I'm not convinced that cloexec-by-default

crusade

quoted

quoted

quoted

makes any sense.  Could somebody give coherent arguments in

favour of

quoted

quoted

quoted

abandoning the existing conventions?

So as I said in the commit message. From a userspace perspective

it's

quoted

quoted

more of an issue if one accidently leaks an fd to a task during

exec.

quoted

quoted

Also, most of the time one does not want to inherit an fd during an
exec. It is a hazzle to always have to specify an extra flag.

As Al pointed out to me open() semantics are not going anywhere.

Sure,

quoted

quoted

no argument there at all.
But the idea of making fds cloexec by default is only targeted at

fds

quoted

quoted

that come from separate syscalls. fsopen(), open_tree_clone(), etc.

they

quoted

quoted

all return fds independent of open() so it's really easy to have

them

quoted

quoted

cloexec by default without regressing anyone and we also remove the

need

quoted

quoted

for a bunch of separate flags for each syscall to turn them into
cloexec-fds. I mean, those for syscalls came with 4 separate flags

to be

quoted

quoted

able to specify that the returned fd should be made cloexec. The

other

quoted

quoted

way around, cloexec by default, fcntl() to remove the cloexec bit

is way

quoted

quoted

saner imho.

Re separate flags - it is, in principle, a valid argument.  OTOH, I'm

not

quoted

sure if they need to be separate - they all have the same value and
I don't see any reason for that to change...

Only tangentially related, but I wonder if something like

close_range(from, to)

quoted

would be a more useful approach...  That kind of open-coded loops is

not

quoted

rare in userland and kernel-side code can do them much cheaper. 

Something

quoted

like
	/* that exec is sensitive */
	unshare(CLONE_FILES);
	/* we don't want anything past stderr here */
	close_range(3, ~0U);
	execve(....);
on the userland side of thing.  Comments?

glibc people need a syscall to implement closefrom properly, see
https://sourceware.org/bugzilla/show_bug.cgi?id=10353#c14

I have a prototype for close_range().
I'll send it out after rc1.

Christian