Problem in the Copy operation

[eshkrig]

Hi.
Sorry for my English.
Previously, copying a file does not change access permissions of the destination file if the check box "Preserve attributes" in the Copy window is not set.
For some time it is not so: if you uncheck the "Preserve attributes" then access permissions of the destination file are set in accordance with the value of umask, which can lead to information disclosure(i.e. security problem).

[eshkrig]

The problem is still present in version 4.7.4

[eshkrig]

the problem is still there:
app-misc/mc-4.7.5.1

[eshkrig]

the problem is still there:
app-misc/mc-4.7.5.2

[andrew_b]

Replying to eshkrig:

Previously, copying a file does not change access permissions of the destination file if the check box "Preserve attributes" in the Copy window is not set. For some time it is not so: if you uncheck the "Preserve attributes" then access permissions of the destination file are setted in accordance with the value of umask,

Yes, that done in #72. But how do you think should be a difference whether "Preserve attributes" is checked or not?

[eshkrig]

IMHO: existing files should only get new content (as earlier versions do)

for example:
-rw------- /path_dst/dir1/secret_file # secret file with old contents
-rw-rw-r-- /path_dst/dir1/some_file

-rw------- /path_src/dir1/secret_file # secret file with new contents

when copying dir
/path_src/dir1 to /path_dst
we have got
-rw-r--r-- /path_dst/dir1/secret_file

That is fail becose structure may contain thousands of hundreds of thousands of catalogs.
And how about ACLs on /path_dst/dir1 ?

As I mention there is security bug for 9 months now (I am sad).

[andrew_b]

Replying to eshkrig:

IMHO: existing files should only get new content (as earlier versions do)

I don't quite understand, why you check "Preserve attributes" off if you want keep permissions.

[eshkrig]

Replying to andrew_b:

I don't quite understand, why you check "Preserve attributes" off if you want keep permissions.

Because here changes the file owner and permissions.

For example as root I often have to modify configuration files in users' home directories.
Before, I could use the MC and the copy prepared files/directories to the user's home directory.

Now the situation is as follows:
If I copy the files with the "Preserve attributes" on - owner of the files is changed to root
If I copy the files with the "Preserve attributes" off - file permissions are changed to 644(-rw-r--r--) and this is not dependent on the established permissions to the source or the destination files

[eshkrig]

The patch, which fixes the problem

[bradatec]

My bug was marked as a dupe of this (#2615) although it seems to me its something different.
In short, when copying files as a root, normal files get correct file/group id but it get wrong for soft links (preserve attributes are on).

[slavazanko]

Created branch 2278_preserve_attrs_if_dest_exists

Review, please.

[slavazanko]

Merged to master: [3907f19a0452ad38f7d0a03bce09c3d7554423a1].

git log --pretty=oneline 68e1b4f..f0f39cb

[slavazanko]

Merged to stable: [d79db98927cbf93625a5661ede2a0832f0d3bd5a].

git log --pretty=oneline 4fd3dee..82dcbe2

[eshkrig]

Thank you.

[onkeltem]

I'm not sure what exactly was fixed but I'm on 4.8.6-1 now and see that copy operation doesn't respect umask set on a remote host when using ssh.

So I connect to a remote via "Shell link...".

There I have umask set via pam_umask to 026.

If I copy a file/directory from local host to the remote and set Preserve Attributes to OFF, then the file/directory is created with 644/755 permissions.

Also I would like to have "Preserve attributes" OFF by default, any ideas how to do this?

UPDATE

After looking in code it becomes clear that MC takes local mask and use it to chmod'ing a remote object:

  else if (!dst_exists)
  {
    src_mode = umask (-1);
    umask (src_mode);
    src_mode = 0100666 & ~src_mode;
    mc_chmod (dst_vpath, (src_mode & ctx->umask_kill));
  }

​https://github.com/MidnightCommander/mc/blob/master/src/filemanager/file.c#L1894

This happens with both SFTP and FISH VFSes which I tested.
The correct behavior would be to not chmod at all when we deal with a remote VFS. So instead of:

  else if (!dst_exists)

there should be something like:

  else if (!dst_exists && !<vfs_is_remote>)

Unfortunately I don't know how to check is a vfs is remote. Please fix this.