Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overwriting a hardlinked file greatly broadens permissions #1593

Open
ag-eitilt opened this issue Jul 10, 2024 · 0 comments
Open

Overwriting a hardlinked file greatly broadens permissions #1593

ag-eitilt opened this issue Jul 10, 2024 · 0 comments
Labels
backlog Task that isn't actively being worked on bug Something isn't working

Comments

@ag-eitilt
Copy link
Collaborator

Split from #1589: If a Wake job overwrites a file which has been hardlinked to elsewhere, the known output is delinked and overwritten as expected. However, the remaining copy of the inode suddenly gains 777 permissions.

$ wake -x 'makePlan "test" Nil "echo -n test > test.txt" | runJob' ; ln test.txt test2.txt ; chmod -w test2.txt ; wake -x 'makePlan "test" Nil "echo -n test with different contents > test.txt" | runJob'
Job 9666
Job 9679
$ ls -l test.txt test2.txt
-rwxrwxrwx 1 sammay sammay  4 Jul  8 12:48 test2.txt
-rw-r--r-- 1 sammay sammay 28 Jul  8 12:48 test.txt

Our guess during the meeting is that this is a problem with our FUSE sandboxing, likely somewhere in deep_unlink and specifically if the file isn't writable, trying to deinitialize the inode without realizing that it's still accessible. So far as we can tell this doesn't provide a vector for permission escalation attacks as the Linux permission system would block any attempt to change permissions on files which the user running Wake wouldn't already have access to, but it is technically possible to construct a script which calls ln [...]/target.file . a victim into a Wake workspace and deliberately overwrite that to expose the original -- it's simply also possible to chmod 777 [...]/target.file directly.

Our determination is that this is definitely a problem which needs to be fixed, but isn't a critical problem to drop everything for. It also points to the fact that we likely shouldn't be rolling our own FUSE implementation, and that switching that whole subsystem out for overlayfs would eliminate a whole category of potential bugs lurking in edge cases such as this.

@ag-eitilt ag-eitilt added bug Something isn't working backlog Task that isn't actively being worked on labels Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Task that isn't actively being worked on bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant