runat: Add -h to manipulate a symbolic link's named attribute dir

[rmacklem]

Summary

Lionel Cons <[e-mail]> requested
that a new option be added to runat(1) so that it could
be used to manipulate named attributes associated with
a symbolic link 9and not the file the symbolic link refers to).

This patch adds the option -h/--nofollow to do this.

Test Plan

Tested for symbolic links (and non-symbolic links)
on ZFS with xattr=dir both locally and over a NFSv4
mount.

[kib]

usr.bin/runat/runat.c

89

Why do we need to ensure that? What if we silently continue operating on it, even without a warning?

[kib]

usr.bin/runat/runat.c

43–58

Why not set O_PATH unconditionally? file_fd seems to be only used for the dirfd argument of the openat() call.

[kib]

BTW, chmod(1), chflags(1), ls(1) and find(1) consistently use -P for the same functionality. ls(1) does not fail if the argument is not a symbolic link.

[rmacklem]

In D55023#1257715, @kib wrote:

BTW, chmod(1), chflags(1), ls(1) and find(1) consistently use -P for the same functionality. ls(1) does not fail if the argument is not a symbolic link.

I can switch it to "-P". It was Lionel Cons that suggested "-S".

usr.bin/runat/runat.c

43–58

Yea, I cannot think of a reason to not set O_PATH.

89

I've asked on freebsd-hackers@ (where the request
showed up) to see what others think.

To be honest, I cannot think why anyone would
put named attributes (Solaris extended attributes)
on a symlink, so I thought it should fail if that wasn't
what was wanted? However I don't have a strong opinion.
I'll see what others say.
--> Btw, the Solaris runat(1) command does not have an

option to do this, so I am not sure why Lionel Cons wants it?

[rmacklem]

In D55023#1257720, @rmacklem wrote:

In D55023#1257715, @kib wrote:

BTW, chmod(1), chflags(1), ls(1) and find(1) consistently use -P for the same functionality. ls(1) does not fail if the argument is not a symbolic link.

I can switch it to "-P". It was Lionel Cons that suggested "-S".

One difference is that -P seems to be the default (for find(1) and ls(1)).

The Solaris runat(1) always follows the symlink.
lsextattr follows the symlink by default.
lsextattr -h does not follow the symlink, but doesn't

fail if it is not a symlink.

--> I suppose that it makes sense to do what lsextattr does,

since that is the other way to access these extended attributes.

I'll wait to see what others say on the mailing list.

[jilles]

In D55023#1257720, @rmacklem wrote:

In D55023#1257715, @kib wrote:

BTW, chmod(1), chflags(1), ls(1) and find(1) consistently use -P for the same functionality. ls(1) does not fail if the argument is not a symbolic link.

I can switch it to "-P". It was Lionel Cons that suggested "-S".

Looking at symlink(7), I think "-h" would be a more expected option letter here (like chflags, chgrp, chmod, chown). In most cases, "-P"/"-H"/"-L" only affect directory tree walks (typically with "-R").

[rmacklem]

As suggested by jilles@ and to be more consistent
with rmextattr(8), change "-S/--symlink" to "-h/--nofollow".

As suggested by kib@:

• Set O_PATH unconditionally.
• Remove the check for file being a symbolic link, which is also more consistent with rmextattr(8).

[rmacklem]

usr.bin/runat/runat.c

89

There were no other comments on freebsd-hackers@
w.r.t. whether or not a check for file being a symbolic
link. As such, I removed the check to be more consistent
with other commands with a similar flag.