[dev] [sbase] chmod -R and symbolic links

From: Michael Forney <mforney_AT_mforney.org>
Date: Sat, 21 Dec 2019 19:05:45 -0800

Hi,

I'm looking into improving chmod(1) behavior with symbolic links.

First, some background:
- The mode of symbolic links is not used anywhere, and on linux,
fchmodat(AT_FDCWD, path, mode, AT_SYMLINK_NOFOLLOW) on a symlink
returns EOPNOTSUPP.
- POSIX only specifies the -R option, and doesn't say anything about
symbolic links.
- coreutils and busybox chmod(1) only have a -R option. For directory
traversal, they follow symlinks specified on the command-line (an
error is printed if it is dangling), but don't follow symlinks
encountered further down.
- Most BSD chmod(1) have -H, -L, and -P options (defaulting to -P),
and the filesystem *does* record the mode of a symlink, but this mode
has no affect on the kernel's access checks.
- sbase chmod(1) has -H, -L, and -P options (defaulting to -P), which
control how recurse() traverses the directory tree. The option do
*not* affect the calls to chmod(3) itself, which always follows
symlinks.

So currently, if sbase chmod -R encounters a dangling symlink, it always fails.

I can think of two possibilities here:

1. Remove the -H, -L, and -P options from chmod, always set r.follow =
'H', and call chmod(3) conditional on !S_ISLINK(st->st_mode).
2. Keep the -H, -L, and -P options, but use fchmodat(3) instead of
chmod(3) with AT_SYMLINK_NOFOLLOW depending on r->follow and r->depth.
If fchmodat fails with EOPNOTSUPP, ignore that and continue.

Does anyone have a strong preference for 2? I'm leaning towards 1
since it doesn't seem like those options are used commonly.

-Michael
Received on Sun Dec 22 2019 - 04:05:45 CET