Re: FreeBSD runat(1) option to open a symlink named attr dir?

On Sat, Jan 31, 2026 at 1:59 PM Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
>
> On Sat, Jan 31, 2026 at 01:37:02PM -0800, Rick Macklem wrote:
> > On Sat, Jan 31, 2026 at 1:23 PM Rick Macklem <rick.macklem@gmail.com> wrote:
> > >
> > > On Fri, Jan 30, 2026 at 11:17 AM Lionel Cons <lionelcons1972@gmail.com> wrote:
> > > >
> > > > Can we please get a runat(1) option to open the named attr dir of a symlink?
> > > >
> > > > For example add an option -S (and -- end of argument handling) to open
> > > > the base file,dir,symlink with open(argv[1],
> > > > O_RDONLY|O_NOFOLLOW|O_PATH))
> > > The patch that does this can be found at https://reviews.freebsd.org/D55023
> > The current patch causes runat(1) to fail when "-S" is specified and the file
> > is not a symbolic link.
> >
> > A reviewer asked "Why not just let it process the non-symbolic link?".
> >
> > What do others think..should it fail for "-S" if the file is not a symbolic
> > link or should it function anyway (possibly with a warning)?
>
> There isn't really a point to this (my) email other than to share some
> anecdotal data points.
>
> From a cursory glance, it looks like there's two ways of approaching
> symlinks:
>
> 1. Default to nofollow. This is the default behavior of zsh's built-in
>    ls. One must pass in the -H flag to follow.
> 2. Default to follow. This is the default behavior of FreeBSD's
>    /bin/ls (as of this writing, of course).
Is it? When I use "-P" (for nofollow) I always get the same thing
as the default (it shows the symlink). To get what the symlink refers
to, I have to use -L.
(But I'm not sure it matters for this case, which is handling of
extended attributes, although Lionel and friends don't like me
calling them that. It's the Solaris mechanism for extended attributes.)

>
> From a security perspective, I prefer t4o default to nofollow. But I
> can see how that could be confusing to folks. So while I have no
> strong opinion here, I do slightly lean towards the nofollow side.
Well, lsextattr and friends (rmextattr(8)) follow the symlink by default
and the Solaris runat(1) always follows the symlink.
As such, I think following the symlink by default would be more
consistent, but I don't have a strong opinion.

lsextattr and friends uses "-h" to handle the symlink instead
of what the symlink refers to, but doesn't fail if the filename
is not a symlink.

I am tempted to follow the lsextattr "-h" semantics, but
I am interested to see if others have an opinion?

rick

>
> I relatively recently rewrote the tool HardenedBSD uses to toggle
> exploit mitigations (hbsdcontrol(8)). hbsdcontrol uses filesystem
> extended attributes to store its toggle data. It defaults to erroring
> out if a user passed a symlink rather than the actual executable. We
> decided to follow zsh's ls flag of -H.
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
> Signal Username:  shawn_webb.74
> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc