tar problem: Cannot open: Permission denied

[ryniker]

Run as ordinary (non-privileged) user (on Raspberry Pi armv6, but that may not be relevant)

Download https://ftp.gnu.org/gnu/bash/bash-4.4.tar.gz

bash-4.3$ tar xzf bash-4.4.tar.gz tar: bash-4.4/tests/history.list: Cannot open: Permission denied tar: bash-4.4/po/Rules-quot: Cannot open: Permission denied tar: bash-4.4/po/boldquot.sed: Cannot open: Permission denied tar: bash-4.4/po/en@boldquot.header: Cannot open: Permission denied tar: bash-4.4/po/en@quot.header: Cannot open: Permission denied tar: bash-4.4/po/insert-header.sin: Cannot open: Permission denied tar: bash-4.4/po/quot.sed: Cannot open: Permission denied tar: bash-4.4/po/remove-potcdate.sin: Cannot open: Permission denied tar: Exiting with failure status due to previous errors bash-4.3$ id uid=501(ryniker) gid=501(ryniker) groups=501(ryniker) bash-4.3$

The distinguishing feature of these files is they have 0444 permissions, but the important point may be these are the only files in the archive with user r instead of user rw permission.

The tar program used is the one installed by opkg install tar.

[evangreen]

Good find. I'll look into this.

[evangreen]

This is a bug in our code. The file creation happens deep in IopPathWalk (in IopPathLookupThroughFileSystem). But verifying the permissions happens after IopPathWalk has completed. We haven't communicated to the permission checking code that the file was created by this open call, so it finds the permissions (read-only), checks against the permissions desired (read/write), and fails.

Fixing this involves sending an indicator out of the path walk code to say "I was the one who created this, so no need to do permission checking for my open". There are already too many parameters into the path walk code, I don't want to add another. But I notice that 3 of them are already associated with creation (TypeOverride, OverrideParameter, and CreatePermissions).

So my plan is to combine those together into a "create parameters" structure, then add my flag for "did create". Then the create open will succeed, but opens that did not result in the file's inception will continue to fail.

[evangreen]

I've pushed change 68a30a23f1765fa569da6bd29572948291aed50e to address this. The logical differences are fairly small (if I created the file, don't do permission checks when I try to open it). But the diff is intrusive because I was moving parameters into a struct.

If you've got time, give it a try.

[evangreen]

I believe this is fixed, feel free to reopen if there are still issues.