NetBSD Problem Report #563
From gnats Mon Nov 7 20:06:40 1994
Received: from bloom-beacon.MIT.EDU (brnstnd@kramden.acf.nyu.edu@BLOOM-BEACON.MIT.EDU [18.181.0.26]) by sun-lamp.cs.berkeley.edu (8.6.9/8.6.9) with ESMTP id UAA14003 for <gnats-bugs@sun-lamp.cs.berkeley.edu>; Mon, 7 Nov 1994 20:06:39 -0800
Message-Id: <199411080238.VAA07998@kolvir.blrc.ma.us>
Date: Mon, 7 Nov 1994 21:38:55 -0500
From: John Kohl <jtk@kolvir.blrc.ma.us>
Reply-To: jtk@kolvir.blrc.ma.us
To: gnats-bugs@sun-lamp.cs.berkeley.edu
Subject: chmod vs. symlinks: bits don't propagate?
X-Send-Pr-Version: 3.2
>Number: 563
>Category: standards
>Synopsis: chmod doesn't add rights when called via symlink
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bjh21
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Nov 07 20:20:03 +0000 1994
>Closed-Date: Sun Jul 07 11:53:34 +0000 2002
>Last-Modified: Sun Jul 07 11:53:34 +0000 2002
>Originator: John Kohl
>Release: 1.0
>Organization:
" "
>Environment:
System: NetBSD kolvir 1.0 NetBSD 1.0 (KOLVIR) #60: Sat Nov 5 08:56:32 EST 1994 jtk@kolvir:/u1/NetBSD-1.0/src/sys/arch/i386/compile/KOLVIR i386
>Description:
When I ran chmod(1) on a symlink, I expected to see the modes reflected
on the symlink's target's inode, but they aren't.
I suspect chmod may be looking at the (apparent) modes of the symlink
rather than the modes of the target file.
>How-To-Repeat:
% cd /tmp
% touch aaaa
% chmod 400 aaaa
% ln -s aaaa bbbb
% ls -l aaaa bbbb
-r-------- 1 jtk wheel 0 Nov 7 21:27 aaaa
lrwxrwxrwt 1 root wheel 4 Nov 7 21:27 bbbb -> aaaa
% chmod u+w bbbb
% ls -l aaaa bbbb
-r-------- 1 jtk wheel 0 Nov 7 21:27 aaaa
lrwxrwxrwt 1 root wheel 4 Nov 7 21:28 bbbb -> aaaa
!!! shouldn't aaaa have been rw------- ? !!!
% chmod u+w aaaa
% ls -l aaaa bbbb
-rw------- 1 jtk wheel 0 Nov 7 21:27 aaaa
lrwxrwxrwt 1 root wheel 4 Nov 7 21:28 bbbb -> aaaa
>Fix:
Probably something to do with stat(2) vs. lstat(2)?
>Release-Note:
>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: jtk@kolvir.Arlington.MA.US
Cc: gnats-bugs@gnats.netbsd.org, gnats-bugs@sun-lamp.cs.berkeley.edu
Subject: Re: bin/563: chmod vs. symlinks: bits don't propagate?
Date: Sun, 14 Jan 1996 21:55:35 +1100
from reading chmod(1):
-H If the -R option is specified, symbolic links on the command line
are followed. (Symbolic links encountered in the tree traversal
are not followed.)
-L If the -R option is specified, all symbolic links are followed.
-P If the -R option is specified, no symbolic links are followed.
however, the -H and -L flags seem to be ignored:
% cd /tmp
% touch aaaa
% chmod 400 aaaa
% ln -s aaaa bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
% chmod u+w bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
% chmod -H u+w bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
% chmod -L u+w bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
the only meantion of symbolic links in the chmod(2) manual is for ELOOP.
has our chmod(2) been changed to not follow symlinks?
this line from vfs_syscalls:sys_chmod() says otherwise:
NDINIT(&nd, LOOKUP, FOLLOW, UIO_USERSPACE, SCARG(uap, path), p);
if i'm reading it correctly.
hmm?
.mrg.
From: matthew green <mrg@eterna.com.au>
To: jtk@kolvir.Arlington.MA.US
Cc: gnats-bugs@gnats.netbsd.org, gnats-bugs@sun-lamp.cs.berkeley.edu
Subject: Re: bin/563: chmod vs. symlinks: bits don't propagate?
Date: Sun, 14 Jan 1996 21:55:35 +1100
from reading chmod(1):
-H If the -R option is specified, symbolic links on the command line
are followed. (Symbolic links encountered in the tree traversal
are not followed.)
-L If the -R option is specified, all symbolic links are followed.
-P If the -R option is specified, no symbolic links are followed.
however, the -H and -L flags seem to be ignored:
% cd /tmp
% touch aaaa
% chmod 400 aaaa
% ln -s aaaa bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
% chmod u+w bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
% chmod -H u+w bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
% chmod -L u+w bbbb
% ls -l aaaa bbbb
-r-------- 1 mrg wheel 0 Jan 14 21:45 aaaa
lrwxrwxrwt 1 root wheel 4 Jan 14 21:45 bbbb -> aaaa
the only meantion of symbolic links in the chmod(2) manual is for ELOOP.
has our chmod(2) been changed to not follow symlinks?
this line from vfs_syscalls:sys_chmod() says otherwise:
NDINIT(&nd, LOOKUP, FOLLOW, UIO_USERSPACE, SCARG(uap, path), p);
if i'm reading it correctly.
hmm?
.mrg.
From: John Kohl <jtk@kolvir.arlington.ma.us>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@gnats.netbsd.org, jtc@NetBSD.ORG
Subject: Re: bin/563: chmod vs. symlinks: bits don't propagate?
Date: Thu, 16 May 1996 00:08:20 -0400 (EDT)
I think I found the problem in src/bin/chmod.c.
Hflag is only interpreted to follow symlinks if Rflag is also set, so
this works:
chmod -R -H u-w /tmp/bbbb
but this does not
chmod -H u-w /tmp/bbbb
I think the fix is to move the Hflag test outside of the "if (Rflag)" test.
JTC, is there any POSIX issue here that we need to be aware of?
==John
From: matthew green <mrg@eterna.com.au>
To: John Kohl <jtk@kolvir.arlington.ma.us>
Cc: gnats-bugs@gnats.netbsd.org, jtc@netbsd.org
Subject: Re: bin/563: chmod vs. symlinks: bits don't propagate?
Date: Thu, 16 May 1996 14:32:26 +1000
Hflag is only interpreted to follow symlinks if Rflag is also set, so
which is how it is documented to work..
i think this PR can be closed, unless you want to change the meaning
of -H ?
.mrg.
ps: if i had read the man page closer when i first replied to this
PR, maybe we would have fixed it back then ? :-)
From: John Kohl <jtk@kolvir.arlington.ma.us>
To: mrg@eterna.com.au
Cc: gnats-bugs@gnats.netbsd.org, jtc@NetBSD.ORG
Subject: Re: bin/563: chmod vs. symlinks: bits don't propagate?
Date: Thu, 16 May 1996 18:49:11 -0400 (EDT)
>>>>> "mrg" == matthew green <mrg@eterna.com.au> writes:
mrg> Hflag is only interpreted to follow symlinks if Rflag is also set, so
mrg> which is how it is documented to work..
mrg> i think this PR can be closed, unless you want to change the meaning
mrg> of -H ?
Actually, I do want to change it. It seems there should be some way to
chmod something via a symlink, without the risk of a recursive tree
walk.
==John
From: jconklin@netcom.com (J.T. Conklin)
To: jtk@kolvir.arlington.ma.us (John Kohl)
Cc: mrg@eterna.com.au, gnats-bugs@netbsd.org, jtc@netbsd.org
Subject: Re: bin/563: chmod vs. symlinks: bits don't propagate?
Date: Thu, 16 May 1996 17:02:02 -0700 (PDT)
> >>>>> "mrg" == matthew green <mrg@eterna.com.au> writes:
>
> mrg> Hflag is only interpreted to follow symlinks if Rflag is also set, so
>
> mrg> which is how it is documented to work..
>
> mrg> i think this PR can be closed, unless you want to change the meaning
> mrg> of -H ?
>
> Actually, I do want to change it. It seems there should be some way to
> chmod something via a symlink, without the risk of a recursive tree
> walk.
I think it's a little late to go about changing behavior at this time,
but I think John's point has merit. I'll look into whether the POSIX
folks have done anything with symlinks and userlevel utilities yet.
--jtc
From: John Kohl <jtk@kolvir.arlington-heights.ma.us>
To: jtc@netbsd.org, mrg@netbsd.org, gnats-bugs@gnats.netbsd.org
Cc: Subject: Re: bin/563: chmod vs. symlinks: bits don't propagate?
Date: Tue, 8 Jul 1997 23:10:00 -0400 (EDT)
Here's what I'm running in my current private tree, regarding the
chmod/symlink issue discussed in PR 563.
Would you consider reexamining the PR and the issues discussed there,
and whether this implementation is allowable (vis a vis POSIX.2) and/or
desirable?
==John
cvs diff: Diffing .
Index: chmod.1
===================================================================
RCS file: /u3/cvsroot/src/bin/chmod/chmod.1,v
retrieving revision 1.1.1.2
retrieving revision 1.3
diff -c -r1.1.1.2 -r1.3
*** chmod.1 1997/06/25 02:47:48 1.1.1.2
--- chmod.1 1997/06/25 04:29:03 1.3
***************
*** 44,52 ****
.Nd change file modes
.Sh SYNOPSIS
.Nm chmod
.Oo
.Fl R
! .Op Fl H | Fl L | Fl P
.Oc
.Ar mode
.Ar file ...
--- 44,53 ----
.Nd change file modes
.Sh SYNOPSIS
.Nm chmod
+ .Op Fl H
.Oo
.Fl R
! .Op Fl L | Fl P
.Oc
.Ar mode
.Ar file ...
***************
*** 61,69 ****
The options are as follows:
.Bl -tag -width Ds
.It Fl H
! If the
! .Fl R
! option is specified, symbolic links on the command line are followed.
(Symbolic links encountered in the tree traversal are not followed.)
.It Fl L
If the
--- 62,68 ----
The options are as follows:
.Bl -tag -width Ds
.It Fl H
! Symbolic links on the command line are followed.
(Symbolic links encountered in the tree traversal are not followed.)
.It Fl L
If the
Index: chmod.c
===================================================================
RCS file: /u3/cvsroot/src/bin/chmod/chmod.c,v
retrieving revision 1.1.1.2
retrieving revision 1.3
diff -c -r1.1.1.2 -r1.3
*** chmod.c 1997/06/28 00:59:08 1.1.1.2
--- chmod.c 1997/06/28 02:56:18 1.3
***************
*** 132,143 ****
usage();
fts_options = FTS_PHYSICAL;
if (Rflag) {
if (hflag)
errx(1,
"the -R and -h options may not be specified together.");
- if (Hflag)
- fts_options |= FTS_COMFOLLOW;
if (Lflag) {
fts_options &= ~FTS_PHYSICAL;
fts_options |= FTS_LOGICAL;
--- 132,143 ----
usage();
fts_options = FTS_PHYSICAL;
+ if (Hflag)
+ fts_options |= FTS_COMFOLLOW;
if (Rflag) {
if (hflag)
errx(1,
"the -R and -h options may not be specified together.");
if (Lflag) {
fts_options &= ~FTS_PHYSICAL;
fts_options |= FTS_LOGICAL;
From: "Erik E. Fair" <fair@clock.org>
To: gnats-bugs@netbsd.org
Cc: Subject: bin/563
Date: Mon, 6 Jul 1998 02:30:37 -0700
A quick test with chown(1) exhibits the same behavior; chown works on
files, but not on symlinks (either on the symlink or the link target), by
default.
a data point,
Erik <fair@clock.org>
Responsible-Changed-From-To: gnats-admin->bin-bug-people
Responsible-Changed-By: fair
Responsible-Changed-When: Mon Dec 28 12:40:59 PST 1998
Responsible-Changed-Why:
belongs to bin-bug-people
From: cgd@netbsd.org (Chris G. Demetriou)
To: gnats-bugs@netbsd.org
Cc: jtk@netbsd.org, mrg@netbsd.org, kleink@netbsd.org
Subject: re: bin/563
Date: 03 Jul 1999 03:00:53 -0700
[ klaus cc'd in because in my mind he's taken over the mantle of
'standards weenie.' 8-]
So, I looked at this PR because of the fact that it was on the '10
most wanted' list.
The entire analysis in this PR about the expected behaviour, and the
combination of various flags with -R is incorrect.
The manual page says:
-H If the -R option is specified, symbolic links on the command line
are followed. (Symbolic links encountered in the tree traversal
are not followed.)
-L If the -R option is specified, all symbolic links are followed.
-P If the -R option is specified, no symbolic links are followed.
That is to say, "If the -R option is specific, this flag has this
effect. Otherwise the behaviour is the default behaviour, not
documented here and instead documented in symlink(7)."
The chmod manual page is horrific.
If you read the symlink(7) manual page, you will see:
Commands not traversing a file tree.
[ ... ]
Except as noted below, commands follow symbolic links named as command
line arguments. For example, if there were a symbolic link "slink" which
pointed to a file named "afile", the command "cat slink" would display
the contents of the file "afile".
It is important to realize that this rule includes commands which may op-
tionally traverse file trees, e.g. the command "chown file" is included
in this rule, while the command "chown -R file" is not (The latter is de-
scribed in the third area, below).
If it is explicitly intended that the command operate on the symbolic
link instead of following the symbolic link, e.g., it is desired that
"file slink" display the type of file that "slink" is, whether it is a
symbolic link or not, the -h option should be used. In the above exam-
ple, "file slink" would report the type of the file referenced by
"slink", while "file -h slink" would report that "slink" was a symbolic
link.
There are three exceptions to this rule. The mv(1) and rm(1) commands do
not follow symbolic links named as arguments, but respectively attempt to
rename and delete them. (Note, if the symbolic link references a file
via a relative path, moving it to another directory may very well cause
it to stop working, since the path may no longer be correct).
The ls(1) command is also an exception to this rule. For compatibility
with historic systems (when ls is not doing a tree walk, i.e. the -R op-
tion is not specified), the ls command follows symbolic links named as
arguments if the -L option is specified, or if the -F, -d or -l options
are not specified. (If the -L option is specified, ls always follows
symbolic links. ls is the only command where the -L option affects its
behavior even though it is not doing a walk of a file tree).
The 4.4BSD system differs from historical 4BSD systems in that the chown,
chgrp and file commands follow symbolic links specified on the command
line.
The following section, dealing with recursive tree walks, discusses
the -H, -L and -P flags.
In other words, -H, -L, and -P are meant to only apply to the -R case,
and should generate an error if used without -R (just as -h generates
an error if used with -R). Note also in the chmod manual page the synopsis:
chmod [-R [-H | -L | -P]] [-h] mode file ...
meaning -H, -L, and -P are only to be used with -R.
chmod -h functions correctly. Obviously, if chmod without -h weren't
meant to set the mode of the file behind the symlink, the -h flag
itself would not be necessary.
the reason the symlink wasn't actually being chmodded when no -h was set
was because of the (!hflag) test ca. line 201 of the -current chmod. For
symlinks on the command line, that's bogus.
Therefore, I propose the following things:
* investigate what standards say on this matter. Anybody know?
(Klaus?) What do other systems do when chmod/chown/etc. are given
symlinks on the command line?
* our file doesn't behave as documented in symlink(7), and supports a
-L flag. I propose that that be left as-is, and the comment in
symlink(7) about file be removed. (Also, s/4.4BSD/NetBSD/.)
* change chmod (and any other similar commands: are any of chown,
chgrp, others ??? broken in the same way) to match the behaviour
documented by symlink(7), namely:
* error out if -H, -L, or -P are specified without -R.
* change the synopsis and description in the manual page
to make things clearer.
* make the default behaviour follow symlinks on the command
line (with, as before, -h overriding that).
* make the program return an error if a symlink could not be
chowned when ! -R (i.e. danging link specified on the
command line with no -h).
Comments?
cgd
--
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
From: cgd@netbsd.org (Chris G. Demetriou)
To: gnats-bugs@netbsd.org
Cc: jtk@netbsd.org, mrg@netbsd.org, kleink@netbsd.org
Subject: Re: bin/563
Date: 03 Jul 1999 03:12:14 -0700
cgd@netbsd.org (Chris G. Demetriou) writes:
> * investigate what standards say on this matter. Anybody know?
> (Klaus?) What do other systems do when chmod/chown/etc. are given
> symlinks on the command line?
BTW, about this, the Digital UNIX manual pages say:
[Compaq] If a named file is a symbolic link, chmod changes the mode of the
link's target file unless the -R option is used. If the -R option is used,
chmod leaves links and their target files untouched.
In other words, it's consistent with the behaviour of -R (with none or -P specified), and with the proposed behaviour of !-R.
To quote futher sections of symlink(7):
As consistently as possible, you can specify the default behavior by
specifying the -P (for "physical") flag. This flag is intended to make
the entire name space look like the physical name space.
also, contrary to what i said previously, in the recursive-walk section:
For example, the command "chown -R user slink directory" will ignore
"slink", because the -h flag must be used to change owners of symbolic
links. Any symbolic links encountered during the tree traversal will al-
so be ignored. The command "rm -r slink directory" will remove "slink",
as well as any symbolic links encountered in the tree traversal of
"directory", because symbolic links may be removed. In no case will ei-
ther chown or rm affect the file which "slink" references in any way.
so, -h should be combinable with -R, but possibly not with -L. (It
depends on what the desired behaviour is: should dangling symlinks be
changed in the -R -L case?)
FWIW, i'm going to ping Keith Bostic and see if he has any input on
this. I seem to recall him agonizing over the behaviour of all of
these flags N years ago...
cgd
--
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
From: Erik Fair <fair@clock.org>
To: cgd@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/563
Date: Fri, 5 May 2000 12:16:29 -0700
Chris,
Did Keith Bostic ever reply to your query about this PR?
Erik <fair@clock.org>
From: cgd@netbsd.org (Chris G. Demetriou)
To: Erik Fair <fair@clock.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/563
Date: 05 May 2000 12:27:20 -0700
Erik Fair <fair@clock.org> writes:
> Chris,
> Did Keith Bostic ever reply to your query about this PR?
no.
--
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
Responsible-Changed-From-To: bin-bug-people->standards-manager
Responsible-Changed-By: fair
Responsible-Changed-When: Sat May 6 01:33:53 PDT 2000
Responsible-Changed-Why:
the discussion in this PR has revolved around standards, and barring some
research on the issue by our standards people, this PR will probably
continue to languish.
From: Ben Harris <bjh21@netbsd.org>
To: <gnats-bugs@gnats.netbsd.org>
Cc:
Subject: standards/563
Date: Sun, 30 Jun 2002 11:10:57 +0100 (BST)
IEEE Std 1003.1-2001 includes symbolic links, and is conveniently on the
Web, so I've looked this up.
<http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_11>:
# If a symbolic link is encountered during pathname resolution [...] If
# all of the following are true, then pathname resolution is complete:
#
# * This is the last pathname component of the pathname.
# * The pathname has no trailing slash.
# * The function is required to act on the symbolic link itself, or
# certain arguments direct that the function act on the symbolic link
# itself.
<http://www.opengroup.org/onlinepubs/007904975/utilities/chmod.html>
contains no references to symbolic links, and as such seems to fail the
third requirement above, and hence chmod(1) should, when used according to
the standard, act on the target of the link. What we do when any of -hHLP
are specified is up to us.
Thus, from a standards point-of-view, chmod(1) needs to be changed so that
when used without options it works through symlinks specified on the
command line.
Much the same applies to chown(1), though there POSIX specifies the
semantics of -hHLP. As far as I can tell, for -h without -R, it specifies
the same semantics as symlink(7), so I plan to implement that for both
chmod and chown. I haven't yet worked out whether POSIX and symlink(7)
are equivalent for -R.
--
Ben Harris <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26 <URL:http://www.netbsd.org/Ports/acorn26/>
State-Changed-From-To: open->feedback
State-Changed-By: bjh21
State-Changed-When: Sun Jul 7 04:44:58 PDT 2002
State-Changed-Why:
I believe this is fixed by chmod.c rev 1.28.
Submitter, if you're still out there, please test and confirm the fix.
Responsible-Changed-From-To: standards-manager->bjh21
Responsible-Changed-By: bjh21
Responsible-Changed-When: Sun Jul 7 04:44:58 PDT 2002
Responsible-Changed-Why:
I committed the fix.
State-Changed-From-To: feedback->closed
State-Changed-By: bjh21
State-Changed-When: Sun Jul 7 04:52:56 PDT 2002
State-Changed-Why:
Submitter e-mail bounced. Assume the fix works.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home