one more openat-style function required: fchmodat

[Jim Meyering <jim at meyering dot net>]

Please consider adding an fchmodat function, analogous to fchownat.

I've rewritten coreutils' fts.c not to change the current
working directory.  That included adjusting the clients
that use fts: du, chmod, chown, chgrp.

In the process, I found that neither Solaris nor glibc
provides a directory-fd-relative chmod function, which I needed
for src/chmod.c.  It is straightforward to simulate the
function using /proc/self/fd/<dir_fd_num>/<file_name> or
save_cwd/fchdir/chmod/restore_cwd, but it'd be better to have a
native (and glibc-supported) implementation to go along with all
of the other ones.

Since Solaris didn't add that interface[*], I'm wondering if I'm missing
something.  Can it be simulated some other way?  Using openat and
fchmod is not adequate, because openat fails for inaccessible files.
If a file were chmod'd to 0 (or even to u-rw), we'd be unable to
adjust permissions without first using chdir.

A google search for chmodat found nothing interesting, but there
is a single, tantalizing reference to a Solaris function named fchmodat.
It's an entry in the _Index for Solaris Systems Programming_:

  fchmodat function, 597-599

If anyone knows more about that, please share.

In case you're wondering how/why chmod -R now needs fchmodat,
it's because this new version of fts traverses the hierarchy via
a virtual working directory.  As a result, the driver chmod.c is
no longer fchdir/chdir'd to each directory, but instead gets a file
descriptor, FD, open on each.  So rather than chmod (file, mode),
it now needs to do something like fchmodat (FD, file, mode, 0).

------
[*] but Solaris didn't add mkdirat either, so maybe the lack of
fchmodat means nothing.