After the bspatch program applies a delta to FILE1 to produce FILE2, it runs chmod(2) and chown(2) to set permissions and ownership for FILE2 according to the metadata in the delta file.
This behavior is a convenience for some use cases. For example, consumers of the delta files (like swupd from swupd-client) do not have to bother running the ownership/permission modifications on FILE2 after an update.
But from a testing perspective, requiring root privileges to apply delta files is an inconvenience when those delta files specify to change ownership to an arbitrary user ID and group ID, and the user running the test suite might lack privileges to carry out the operation.
To sidestep the root requirement, it would be nice to either make the chmod(2) and chown(2) calls optional in some way, or add a mechanism to hotpatch delta files on-the-fly to set the user/group ID to the effective user/group ID of the calling process, specifically for the test suite.
After the
bspatchprogram applies a delta to FILE1 to produce FILE2, it runschmod(2)andchown(2)to set permissions and ownership for FILE2 according to the metadata in the delta file.This behavior is a convenience for some use cases. For example, consumers of the delta files (like
swupdfrom swupd-client) do not have to bother running the ownership/permission modifications on FILE2 after an update.But from a testing perspective, requiring root privileges to apply delta files is an inconvenience when those delta files specify to change ownership to an arbitrary user ID and group ID, and the user running the test suite might lack privileges to carry out the operation.
To sidestep the root requirement, it would be nice to either make the
chmod(2)andchown(2)calls optional in some way, or add a mechanism to hotpatch delta files on-the-fly to set the user/group ID to the effective user/group ID of the calling process, specifically for the test suite.