Hmm. In this case it's really the kernel that is writing the xattr, so in that case #2 kind of makes sense. It's also more than a bit scary, assigning CAP_SYS_ADMIN in init_user_ns to a task from a user namespace. Now we're already doing it for unprivileged users in init_user_ns which isn't all that different, except for the fact that in the user namespace that unprivileged user can also create the overlay mount, and that leaves me feeling a bit uneasy. I'm not familiar enough with overlayfs to decide whether or not this really presents an opportunity for someone to do something malicious to the lower fs.
With #1, I don't think we have a way to distinguish between overlayfs trying to write this xattr and userspace writing it directly, do we? This also might present an opportunity for a user to do something mildly malicious.
I can't comment on #3, I just don't know enough about overlayfs.
I don't really any other ideas. #2 seems the most logical to me if we can be sure that it's safe.
Hmm. In this case it's really the kernel that is writing the xattr, so in that case #2 kind of makes sense. It's also more than a bit scary, assigning CAP_SYS_ADMIN in init_user_ns to a task from a user namespace. Now we're already doing it for unprivileged users in init_user_ns which isn't all that different, except for the fact that in the user namespace that unprivileged user can also create the overlay mount, and that leaves me feeling a bit uneasy. I'm not familiar enough with overlayfs to decide whether or not this really presents an opportunity for someone to do something malicious to the lower fs.
With #1, I don't think we have a way to distinguish between overlayfs trying to write this xattr and userspace writing it directly, do we? This also might present an opportunity for a user to do something mildly malicious.
I can't comment on #3, I just don't know enough about overlayfs.
I don't really any other ideas. #2 seems the most logical to me if we can be sure that it's safe.