Handle {error, eacces} in get_attrs/6 in ssh_sftpd.erl

[alanj853]

Problem

I think the get_attrs/6 function in ssh_ftpd.erl (https://github.com/erlang/otp/blob/master/lib/ssh/src/ssh_sftpd.erl#L567) should be set up to handle {error, eacces} (and maybe other errors too) the same as {error, enoent} when running the FileMod:read_link_info/2 function. If the error is anything other than {error, enoent}, the xf_send_names/3 in ssh_xfer.erl will crash with the following:

11:55:24.866: [error] gen_server.error_info/7 : GenServer #PID<0.3240.0> terminating
** (ArgumentError) argument error
    :erlang.length({:error, :eacces})
    (ssh 4.10) src/ssh_xfer.erl:277: :ssh_xfer.xf_send_names/3
    (ssh 4.10) src/ssh_sftpd.erl:483: :ssh_sftpd.read_dir/6
    (ssh 4.10) src/ssh_sftpd.erl:193: :ssh_sftpd.handle_data/3
    (ssh 4.10) src/ssh_sftpd.erl:132: :ssh_sftpd.handle_ssh_msg/2
    (ssh 4.10) ssh_client_channel.erl:263: :ssh_client_channel.handle_info/2
    (stdlib 3.13) gen_server.erl:680: :gen_server.try_dispatch/4
    (stdlib 3.13) gen_server.erl:756: :gen_server.handle_msg/6 
    (stdlib 3.13) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
Last message: {:ssh_cm, #PID<0.3232.0>, {:data, 0, 0, <<0, 0, 0, 10, 12, 0, 0, 0, 4, 0, 0, 0, 1, 48>>}}
State: {:state, #PID<0.3232.0>, :ssh_sftpd, {:state, {:ssh_xfer, 3, [], #PID<0.3232.0>, 0}, '/', '/root_dir', :undefined, "", FileManager, %{user: "user1"}, 0, [root: '/root_dir', cwd: '/', file_handler: {FileManager, %{user: "user1"}}], [{0, :directory, {'/ssh/', :unread}}]}, 0, false}

(it may be worth noting that I am running this from Elixir, and am checking a file where eacces is being returned)

If the user is to use the default FileMod of ssh_sftp_file, the erlang module https://erlang.org/doc/man/file.html will be used and file:read_link_info/1 will be called. file:read_link_info/1 can return more than just {error, enoent} (see https://erlang.org/doc/man/file.html#type-posix), so even if the user uses the default FileMod this crash can occur.

Possible Solution

A clear and concise description of what you want to happen.
The solution here I think is to handle {error, eacces} and possibly other error cases the same as {error, enoent}. See https://github.com/alanj853/otp/pull/1/files#diff-3633e8b884563ad1c24bf23c387c168fd21c25f5bbbdc73d4ef3010f6b106e04R569 for an example.

Perhaps there is a reason why enoent is the only case that is handled differently, and if so, can somebody please tell me why this is the case.

[HansN]

Solved in the next release OTP-24.1 by PR #5167