You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the things left for future work in #3396 was xattr support for Android, as part of the implementation for cp --archive. I tested that xattrs do work on Android, and we can set them, so the upstream xattr library we use merged a PR for Android support. Yay. \o/
Poking around with strace, it appears the problem is the SELinux xattrs. SELinux is part of Android's security model (i.e., how it prevents one app from mucking around with another app), and SELinux is implemented, in part, using security xattrs, so it makes sense that Android wouldn't allow us to touch those -- even though in our tests, the value we're trying to write is the value those files would have anyway (the source and dest are owned by us). I did an strace | grep xattr on GNU's cp --archive, and they're not calling any of the xattr syscalls on Android, even listxattr, which implies they simply chose not to support xattrs on that platform.
Right now, cp --archive is crashing for us on Android, and doesn't in GNU's implementation, so something needs to change. The question is what. The way I see it, we have 3 options:
Directly copy GNU behavior, and just drop support for xattrs entirely on Android. Pros: Nobody can really complain much, we're just matching the exiting tools. Cons: Seems like a waste to drop support entirely for just one unsupported xattr.
On Android, specifically skip security xattrs. Pros: Gives us support for every xattr we can use (AFAIK). Cons: Presumably root shells don't have this restriction, so if someone were running cp --archive in one, this would be unexpected.
Handle EACCES errors, and keep going with the rest of the copy, perhaps logging a warning to stderr. Pros: Guaranteed to handle all xattrs we can, even in edge cases like root shells. Cons: If we log, that'll show up in basically every cp --archive call on Android; if we don't log, we could potentially be silently swallowing an error the user would want to know about.
The text was updated successfully, but these errors were encountered:
One of the things left for future work in #3396 was xattr support for Android, as part of the implementation for
cp --archive
. I tested that xattrs do work on Android, and we can set them, so the upstream xattr library we use merged a PR for Android support. Yay. \o/However, after writing a patch to support it here, the relevant tests still fail on Android. Boo. /o\
Poking around with strace, it appears the problem is the SELinux xattrs. SELinux is part of Android's security model (i.e., how it prevents one app from mucking around with another app), and SELinux is implemented, in part, using security xattrs, so it makes sense that Android wouldn't allow us to touch those -- even though in our tests, the value we're trying to write is the value those files would have anyway (the source and dest are owned by us). I did an
strace | grep xattr
on GNU'scp --archive
, and they're not calling any of thexattr
syscalls on Android, evenlistxattr
, which implies they simply chose not to support xattrs on that platform.Right now,
cp --archive
is crashing for us on Android, and doesn't in GNU's implementation, so something needs to change. The question is what. The way I see it, we have 3 options:cp --archive
in one, this would be unexpected.EACCES
errors, and keep going with the rest of the copy, perhaps logging a warning to stderr. Pros: Guaranteed to handle all xattrs we can, even in edge cases like root shells. Cons: If we log, that'll show up in basically everycp --archive
call on Android; if we don't log, we could potentially be silently swallowing an error the user would want to know about.The text was updated successfully, but these errors were encountered: