Bug 2314 - ls -l a_symlink does not list the link permissions
Summary: ls -l a_symlink does not list the link permissions
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp (show other bugs)
Version: -current
Hardware: Other All
: P5 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-15 01:23 AEDT by Kirk Wolf
Modified: 2018-12-29 19:32 AEDT (History)
2 users (show)

See Also:


Attachments
don't override lstat in glob2 for GLOB_MARK processing (974 bytes, text/plain)
2014-11-15 01:23 AEDT, Kirk Wolf
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kirk Wolf 2014-11-15 01:23:27 AEDT
Created attachment 2505 [details]
don't override lstat in glob2 for GLOB_MARK processing

In 1.139 of sftp.c, which was released in 5.7p1:

- djm at cvs.openbsd.org 2010/09/25 09:30:16
     [sftp.c configure.ac openbsd-compat/glob.c openbsd-compat/glob.h]
     make use of new glob(3) GLOB_KEEPSTAT extension to save extra server
     rountrips to fetch per-file stat(2) information.
     NB. update openbsd-compat/ glob(3) implementation from OpenBSD libc to
     match.


This changed the behavior of a symlink listing:

$ sftp -D /usr/lib/openssh/sftp-server
Attached to /usr/lib/openssh/sftp-server.
sftp> !ln -s /etc/profile /tmp/lprofile
sftp> ls -al /tmp/lprofile
-rw-r--r--    0 0        0             665 Jan 21  2014 /tmp/lprofile

prior to 5.7:

sftp -P /usr/lib/ssh/sftp-server                                                                                                                                 
Attaching to /usr/lib/ssh/sftp-server...
sftp> !ln -s /etc/profile /tmp/lprofile
sftp> ls -al /tmp/lprofile
lrwxrwxrwx    1 7001     0              12 Nov 14 08:15 /tmp/lprofile

See a suggested patch to openbsd-compat/glob.c
When using GLOB_KEEPSTAT, don't replace the lstat mode with stat when checking for a symlink to a directory when handling GLOB_MARK
Comment 1 Mike Frysinger 2018-12-29 19:32:49 AEDT
patch makes sense to me, thanks