Impossible to add an executable file to a 7z & zip archive (part of a bigger problem)

[ponko]

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.

[zaytsev]

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?

[ponko]

uar.in

mcarfs_copyin ()
{
    TMPDIR=`mktemp -d "${MC_TMPDIR:-/tmp}/mctmpdir-uar.XXXXXX"` || exit 1
    name=`basename "$2"`
    (cd "$TMPDIR" && cp -fp "$3" "$name" && $XAR r "$1" "$name")
    rm -rf "$TMPDIR"
}

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:

# ls -l
total 8
-rw------- 1 root root 36 Jul  9 09:22 extfs21SQQ27z
-rw------- 1 root root 36 Jul  9 09:22 extfsQFRIQ27z

and this in the log

# cat /tmp/log
/tmp/1/1.7z 7z /tmp/mc-root/extfsQFRIQ27z
/tmp/1/archive.a 7z /tmp/mc-root/extfs21SQQ27z

See? In both cases, $3, fed to the copyin action, has perms 600. The original file was 755.

[ponko]

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

[zaytsev]

Ticket #4628 has been marked as a duplicate of this ticket.

[zaytsev]

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.

• Is this a good idea to copy permissions to $3, or does it really create some problems?
• Can we just use original file for copyin if "local" (non-extfs) or is it too dangerous?

Thinking and patches are welcome.

[ossi]

/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.