On 2020-06-04, Luke Small wrote:
> You can use unveil() on both a symbolic link and the value recovered by
> putting it in realpath(3)! I used it in what I submitted for unveiling
> ftp(1)
You aren't looking at something new, like I said we have been through
*all* of this when we looked at pledge/unveil in nc. A symlink can point
to another symlink. Looking on a typical system using capath the link it
goes like this:
2e5ac55d.0 -> DST_Root_CA_X3.pem
DST_Root_CA_X3.pem -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
(yes it's on another OS, capath doesn't get used much on OpenBSD anyway,
but the option is still there in ftp and this is a common setup for capath).
Yes it is possible to recurse through these until either readlink EINVALs
(you have the file) or returns a path that's already in the list (symlink
loop). My argument is that it adds excessive complexity. A little extra
complexity for a good improvement in security, sure. But there is a
point where the extra complexity makes it so hard to reason about the
code that it's hard to trust and I think handling capath with unveil
breaches that.
