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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net