[Toybox] cp --preserve=a doesn't preserve security context of directories.

[Rob Landley]

So way back in https://github.com/landley/toybox/issues/112 I got a bug report,
which goes with this comment in cp.c:

  // We only copy xattrs for files because there's no flistxattrat()

Which is a symptom, not the problem. The fundamental problem is that creating a
file gives me a filehandle so I can perform operations on the fd and know it
goes to the right inode, but when I mkdir() or mknod() or similar I _can't_ get
a filehandle as part of create.

This leaves an unavoidable gap between create and open where somebody could do a
--bind mount or something and make our later chown/chmod/xattr fiddling apply to
the wrong inode, which is bad juju.

There's various paranoia I can do: for directories I can stat() the fd I just
opened and and confirm S_ISDIR and that .. from there is the expected parent on
the same dev and the uid:gid is us and so on... except that cp -a may be copying
over symlinks and bind mounts and stuff it's supposed to follow. I think the
rule is "we didn't mkdir() so we don't chown/chmod/xattr"? (I have to check
again, and possibly add tests.)

Or, alternately, when creating the parent directory I can create it with
permissions 0700 and then chmod it to the correct permissions in
DIRTREE_COMEAGAIN after finishing with the contents... except I think maybe I
have to move the xattr application to _after_ the chmod because I have no idea
what weird selinux rules are going to veto doing a chmod on the node once
they've been applied? And that doesn't help creating the _first_ directory we're
descending into...

Is there standard security paranoia for handling this sort of thing so I don't
have to reinvent the wheel here? I really don't xattr much so I dunno how you
_expect_ to deal with it...

Rob