sbp opened a new issue, #515: URL: https://github.com/apache/tooling-trusted-releases/issues/515
Because we use hard links to deduplicate artifacts between revisions, when a new revision is staged, files must be deleted before being written to in order to prevent the original data from being overwritten. ``` /tmp # mkdir a b /tmp # echo apple > a/fruit.txt /tmp # cd b /tmp/b # ln ../a/fruit.txt /tmp/b # ls -al fruit.txt -rw-r--r-- 2 root root 6 Jan 14 14:35 fruit.txt /tmp/b # echo banana > fruit.txt /tmp/b # grep . ../a/fruit.txt ../b/fruit.txt ../a/fruit.txt:banana ../b/fruit.txt:banana ``` Note that the metadata of the file is a property of the inode, and not the link. ``` /tmp/b # chmod 400 fruit.txt /tmp/b # ls -al ../a/fruit.txt ../b/fruit.txt -r-------- 2 root root 7 Jan 14 14:35 ../a/fruit.txt -r-------- 2 root root 7 Jan 14 14:35 ../b/fruit.txt ``` This would seem to be an additional consideration, because not only must we take care not to write to files but we must also not change their permissions (and modification time), but we do not use permissions in ATR. We could ensure, as an extra level of protection, that all revision files have read-only permissions before moving them out of the staging area. This would ensure that files must be deleted before writing, which helps to solve the problem. Of course the caller can also change the permissions of a file, and might, for example, accidentally make a file writeable after not deleting the file (e.g. if the deletion failed silently, or if through refactoring complex logic the order were reversed), but all of the cases so far where we accidentally had code writing to a file without deleting it would have been prevented by this. In Nix, the only permissions that they keep track of in archives are whether a file is executable or not. We do not recognise executable files, as all such files must be contained within an archive, so we are unlikely to ever need to track this. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
