Description
Important
This issue was migrated from Trac:
Origin | https://midnight-commander.org/ticket/4558 |
---|---|
Reporter | ponko (ponkotsume@….com) |
I have a 7z archive: /run/shm/1.7z. I open it in the left panel, open /bin in the other panel and copy base64 to the archive. The file gets added to the archive, but as a regular file, NOT as an executable one.
The evident problem is such command used in the u7z extfs script to add the file:
7z a -si"$2" "$1" <"$3" >/dev/null 2>&1
This command takes file data from stdin and, evidently, information about file permissions/mtime is lost.
But there is one more problem. On copying the file into the archive, u7z gets such args:
copyin /run/shm/1.7z base64 /tmp/user/1000/mc-user/extfsOVJKQ2base64
The temp file has perms 600 and is touched with the current time. So, no matter if u7z feeds 7z from stdin or not, there is no way for it to see the original file perms and mtime.
I think, when the extfs (or vfs?) core creates a temp file to feed it to the copyin action, the temp file should have the same perms and mtime as the original.
Activity
mc-butler commentedon Jul 8, 2024
This is weird, in some other scripts care is taken to preserve the permissions while copying or using a symbolic link (see uar.in for a good example). Are you sure that the temp file has wrong permissions and it doesn't work with other archivers as well?
mc-butler commentedon Jul 9, 2024
uar.in
It works directly on $3, but $3 is a temp file created by extfs/vfs core and it always has perms 600, no matter the original perms. I just tried it in an archlinux docker container. I added echo "$@" >> /tmp/log into the copyin functions in u7z and uar.
After adding a file to a 7z and an ar archives I've got this under $MC_TMPDIR:
and this in the log
See? In both cases, $3, fed to the copyin action, has perms 600. The original file was 755.
mc-butler commentedon Jul 9, 2024
In the /tmp/log above "7z" is the file I added to the archives (/bin/7z). Should have used another binary to copy in, it looks confusing as such in the log
mc-butler commentedon Jan 9, 2025
mc-butler commentedon Jan 9, 2025
Ticket #4628 has been marked as a duplicate of this ticket.
mc-butler commentedon Jan 9, 2025
In #4628 the same problem was observed with ZIP archives.
Unfortunately, it seems to be caused by a fundamental issue in extfs design. If I understand it correctly, extfs core creates a temporary file for copyin with permissions set to 600 (and probably other properties reset / changed ownership).
I guess that this was done initially for security reasons. Not sure how we can fix this properly. We can't completely avoid temporary files, unless the source is a local file system.
Thinking and patches are welcome.
mc-butler commentedon Jan 9, 2025
/tmp may be mounted noexec. setuid and xattrs are even less likely to survive.
i'd definitely try to avoid the temporary if possible.
gnu tar supports overriding the stored attributes, though it might be "challenging" to control individual files.
from a quick look it doesn't seem like 7z or zip would support that.
one could write a helper that does that after archive creation, which would also enable supporting mc's chmod, etc. functions directly. https://stackoverflow.com/questions/434641/how-do-i-set-permissions-attributes-on-a-file-in-a-zip-file-using-pythons-zip might be of use.
a different approach would be using bindfs to create a virtual view for the packer, but that's kinda crazy land as far as mc is concerned.