LWN: Comments on "Flags for fchmodat()"

Flags for fchmodat()

jwilk — Thu, 03 Aug 2023 18:24:50 +0000

dup2() was added in V7 Unix (released in 1979), so it predates both POSIX and Linux by about a decade.

Flags for fchmodat()

NYKevin — Thu, 03 Aug 2023 09:00:06 +0000

dup2() is a POSIX-ism, and it appears to be sequential since POSIX also specifies dup(). I would be surprised if Linux named dup2 and then got POSIX to adopt that name (I think dup2 is probably older than that), but I'm insufficiently familiar with the history here to categorically rule it out.

https://pubs.opengroup.org/onlinepubs/9699919799/function...

Flags for fchmodat()

Wol — Sun, 30 Jul 2023 09:23:02 +0000

But puns like that is part of "the Unix way". Go back to the early versions, and Unix is absolutely full of them.

My favourite example is the mutt man page - mutts (dogs) collect mail hence the name, and "mutts don't have bugs, they have fleas ..."

Cheers,
Wol

Flags for fchmodat()

willy — Sun, 30 Jul 2023 03:25:24 +0000

I'm kind of neutral on puns. If they're not needed to make sense (and dup2/wait4 are examples of that), I don't mind. The Lemmings icon of a pair of paws to mean pause is unforgivable.

Flags for fchmodat()

mirabilos — Sun, 30 Jul 2023 03:20:21 +0000

Right, fully agreed there.

I’m not too much of a fan of puns based on specific pronunciations of things, especially if they go unexplained, but it’s probably obvious to english speakers.

Flags for fchmodat()

willy — Sun, 30 Jul 2023 03:08:56 +0000

You can make a similar argument that wait4 was actually "wait for"

Flags for fchmodat()

mirabilos — Sun, 30 Jul 2023 03:03:51 +0000

I think dup2 was actually “dup to”, and no, numbering functions by argument number totally strikes me as unusual and odd when I come by it (e.g. in jq). It’s extremely rare at least in whatever relatively broad but mostly traditional FOSS sphres I’ve been seeing.

It’s also inflexible (what if you change one argument type in a revision, or even lose one).

Flags for fchmodat()

cyphar — Fri, 28 Jul 2023 10:41:58 +0000

> The Linux kernel does not support changing the permission bits on a symbolic link in general (those bits have no real meaning anyway), so neither C-library implementation even tries.

This is actually not quite true, at least not until Christian's patch to enforce this is merged. The restriction on symlink modes was always done on a per-filesystem basis (which lead some filesystems to allowing it by accident -- procfs allows this for several symlinks and magic-links). In fact, several filesystems (btrfs, xfs, and ext4) all returned -EOPNOTSUPP but still modified the inode mode.

> Unfortunately, the obvious way (using fchmod()) won't work, because that system call cannot operate on O_PATH file descriptors in many filesystems. So, instead, the C library generates the path for the open file descriptor under /proc/self/fd, then passes that to chmod() to effect the mode change.

This restriction is done on the VFS level, it's not per-filesystem (fchmod() uses fdget() rather than fdget_raw() -- and this behaviour is intentional per the description of O_PATH in open(2)).

If fchmodat2() adds support for AT_EMPTY_PATH, it would be possible to avoid even procfs nastiness when dealing with O_PATH file descriptors -- something which is necessary in plenty of cases where AT_SYMLINK_NOFOLLOW is inadequate, such as when dealing with paths you need to resolve safely with RESOLVE_IN_ROOT or other openat2() flags). I'll send a patch for this...

Flags for fchmodat()

brauner — Fri, 28 Jul 2023 08:50:12 +0000

There as a discussion a few years back when we did openat2(), clone3() and others that simple versioning is the default.
In sheer numbers this scheme also wins iirc.

There's also the possibility that a system call like bla4() is broken and you'd wanted to change a system call argument type but not the actual number of arguments. Then you'd not be able to call it bla5() and blat4.2() would be rather weird. Imho, the simple versioning is just more flexible and is nowadays the de facto standard anyway.

I also had documentation for all of this but there was never enough time to send it actually but fwiw:

https://github.com/brauner/linux/commit/5fe619ce62bae64cf...

which is part of

https://github.com/brauner/linux/commits/docs_extensible_...

and contains a lot of other info.

Flags for fchmodat()

willy — Fri, 28 Jul 2023 04:10:35 +0000

Funnily, there's not much precedence either way.

Most syscalls that end in a number are 16, 32 or 64, indicating their limits (eg sys_time32)

There's wait/waitpid/wait3/wait4, but the arity matches the sequence number. Similarly for dup/dup2/dup3 and pipe/pipe2

The less said about sys_vm86 the better ;-)

There's signalfd4, eventfd2, epoll_create1, accept4 which look to be arity based.

But then there's renameat2 which has 5 arguments. mlock2 which takes 3. preadv2 and pwritev2 which take 5. openat2 takes 4. faccessat2 takes 4. epoll_pwait2 takes 5.

pselect6 is named for its arity, but that's because you can't normally have more than 6 arguments to a syscall. clone3 was preceded by a clone2 that we don't talk about.

I think you could make an argument either way.

Flags for fchmodat()

wahern — Fri, 28 Jul 2023 03:11:39 +0000

The patch originally used the name fchmodat4, but review requested

s/fchmodat4/fchmodat2/

With very few exceptions we don't version by argument number but by
revision and we should stick to one scheme:

I personally prefer the former, partly perhaps because at some point long ago I was under the impression it was the more the common practice. But more recently I've gotten the impression that most developers are unfamiliar with the version by argument number (i.e. arity) pattern. Have I always been in the minority camp or did the world change around me?

Flags for fchmodat()

Paf — Fri, 28 Jul 2023 00:55:40 +0000

Reading through the earlier thread, it looks like there was some - not entirely positively presented, to be fair - issues with the 2020 submission that have been corrected here, like the lack of tests. So it might’ve been tough to get over the hump before but there were also some issues.

Flags for fchmodat()

bof — Thu, 27 Jul 2023 18:34:13 +0000

Hurray. So in 2-3 years, I can stop the weird extra proc mounts needed inside each rsyncd chroot, again...