Bug 25018

Summary: [libc] lstat(2) returns bogus permissions on symlinks
Product: Base System Reporter: mkamm
Component: kernAssignee: Robert Watson <rwatson>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.2-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description mkamm 2001-02-11 22:50:02 UTC 
I quote a commitlog message here:

##peter       97/03/31 04:03:04
##
##  Treat symlinks as first class citizens with their own uid/gid rather than
##  as shadows of their containing directory.  This should solve the problem
##  of users not being able to delete their symlinks from /tmp once and for
##  all.
##  
##  Symlinks do not have modes though, they are accessable to everything that
##  can read the directory (as before).  They are made to show this fact at
##  lstat time (they appear as mode 0777 always, since that's how the the
##  lookup routines in the kernel treat them).
##  
##  More commits will follow, eg: add a real lchown() syscall and man pages.
##  
##  Revision  Changes    Path
##  1.62      +19 -70    src/sys/kern/vfs_syscalls.c


However the mentioned feature "appear as mode 0777" was broken later
when mount option "nosymfollow" was introduced because the mode was
written to the wrong variable.

For easy reference I quote a part of this second commit log too:

##wosch       1998/04/08 11:32:00 PDT
##  New mount option nosymfollow. If enabled, the kernel lookup()
##  function will not follow symbolic links on the mounted
##  file system and return EACCES (Permission denied).
##  
##  Revision  Changes    Path
##  1.97      +3 -5      src/sys/kern/vfs_syscalls.c
##  1.55      +6 -1      src/sys/kern/vfs_vnops.c

Fix: Don't set a variable that will be overwritten shortly after the
break...
How-To-Repeat: 
(umask 321 && ln -s "have strange but nontheless nonexistant perms" symlinks)
ls -l symlinks

The permissions shown reflect the umask value at the time of the
symlink(2) call rather than the more intuitive "lrwxrwxrwx" or
in case of mount -onosymfollow "l---------".
Comment 1 Bruce Evans 2001-02-12 06:11:43 UTC 
On Sat, 10 Feb 2001 mkamm@gmx.net wrote:

> >How-To-Repeat:
> 
> (umask 321 && ln -s "have strange but nontheless nonexistant perms" symlinks)
> ls -l symlinks
> 
> The permissions shown reflect the umask value at the time of the
> symlink(2) call rather than the more intuitive "lrwxrwxrwx" or
> in case of mount -onosymfollow "l---------".

Fixing this makes lchmod(2) more useless than it already is :-).

Bruce
Comment 2 Robert Watson freebsd_committer freebsd_triage 2008-03-08 20:50:01 UTC 
Responsible Changed
From-To: freebsd-bugs->rwatson

Grab ownership.
Comment 3 dfilter service freebsd_committer freebsd_triage 2008-08-03 16:45:24 UTC 
rwatson     2008-08-03 15:44:56 UTC

  FreeBSD src repository

  Modified files:
    sys/kern             vfs_vnops.c 
  Log:
  SVN rev 181254 on 2008-08-03 15:44:56Z by rwatson
  
  Remove broken code to replace st_mode value with ACCESSPERMS when
  lstat(2) is called on symlinks -- this code appears never to have
  worked.  The PR this addresses suggests that the intended
  original behavior is the right one, but as bde points out in the
  PR comments, we do actually support storing a mode on symlinks,
  so returning it seems reasonable.
  
  This is consistent with Mac OS X, which despite documentation to
  the contrary does return the mode set on a symlink, but not some
  other platforms.  The Single Unix Spec requires only that the
  returned bits be "meaningful", which seems at best unhelpful as
  advice goes.
  
  PR:             25018
  MFC after:      3 days
  
  Revision  Changes    Path
  1.262     +0 -5      src/sys/kern/vfs_vnops.c
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 4 Robert Watson freebsd_committer freebsd_triage 2008-08-03 16:55:02 UTC 
State Changed
From-To: open->patched

Transition to patched as I have removed the bogus code.  This is not the 
change requested in this PR, but does address the issue of the broken 
code.  I'll close the PR once this change has been MFC'd.  Thanks for the 
report, and apologies for the extraordinarily long time it has taken for 
someone to pick up this PR.
Comment 5 dfilter service freebsd_committer freebsd_triage 2008-08-31 22:27:25 UTC 
rwatson     2008-08-31 21:27:05 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_7)
    sys/kern             vfs_vnops.c 
  Log:
  SVN rev 182574 on 2008-08-31 21:27:05Z by rwatson
  
  Merge r181254 from head to stable/7:
  
    Remove broken code to replace st_mode value with ACCESSPERMS when
    lstat(2) is called on symlinks -- this code appears never to have
    worked.  The PR this addresses suggests that the intended
    original behavior is the right one, but as bde points out in the
    PR comments, we do actually support storing a mode on symlinks,
    so returning it seems reasonable.
  
    This is consistent with Mac OS X, which despite documentation to
    the contrary does return the mode set on a symlink, but not some
    other platforms.  The Single Unix Spec requires only that the
    returned bits be "meaningful", which seems at best unhelpful as
    advice goes.
  
    PR:             25018
  
  Revision   Changes    Path
  1.252.2.1  +0 -5      src/sys/kern/vfs_vnops.c
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 6 Robert Watson freebsd_committer freebsd_triage 2009-02-02 11:21:09 UTC 
State Changed
From-To: patched->closed

Close PR as this fix has been merged to 7.x, and was included in 
FreeBSD 7.1.  Thanks for the report and patch!