Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 31 Aug 2001, Terry Lambert wrote: > Bruce Evans wrote: > > No, the empty pathname has been invalid and not an alias for "." since at > > least the first version of POSIX. > > That's the same time they broke signal restart and file > locks, right? Only the file locks :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 31 Aug 2001, Brian F. Feldman wrote: > Bruce Evans <[EMAIL PROTECTED]> wrote: > > On Fri, 31 Aug 2001, Brian F. Feldman wrote: > > > > > Bruce Evans <[EMAIL PROTECTED]> wrote: > > > > Here's an example of a standard utility being clueless about symlinks to > > > > nothing: > > > > > > > > $ ln -s '' foo > > > > $ cp foo bar > > > > cp: foo is a directory (not copied) > > > > > > > > foo is certainly not a directory. The bug seems to be in fts. > > > > > > No, "foo" certainly _is_ a directory. It is precisely the same thing as > > > ".". > > > > No, the empty pathname has been invalid and not an alias for "." since at > > least the first version of POSIX. > > I didn't read the rest of the thread til later ;) The fact remains that > FreeBSD interprets it as such in namei(), and is it not an undefined > behavior according to POSIX? See Garrett's reply. The empty pathname is certainly invalid when passed from userland, but POSIX apparently requires it to "work" when it came from a symlink to "". I concluded the rest of the thread that the POSIX spec is natural, what a lot of namei()'s do, and wrong. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Bruce Evans wrote: > No, the empty pathname has been invalid and not an alias for "." since at > least the first version of POSIX. That's the same time they broke signal restart and file locks, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MFC request (was Re: symlink(2) [Was: Re: tcsh.cat])
This argument is just rehashing something that came up in June. Man
you people have short memories!
I comitted a fix to -current two months ago. It's still in my -stable
tree... if Jordan gives the O.K., I will MFC it to -stable.
-Matt
Index: vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.38.2.2
diff -u -r1.38.2.2 vfs_lookup.c
--- vfs_lookup.c2001/05/20 12:11:57 1.38.2.2
+++ vfs_lookup.c2001/08/31 18:53:22
@@ -200,6 +200,12 @@
break;
}
linklen = MAXPATHLEN - auio.uio_resid;
+ if (linklen == 0) {
+ if (ndp->ni_pathlen > 1)
+ zfree(namei_zone, cp);
+ error = ENOENT;
+ break;
+ }
if (linklen + ndp->ni_pathlen >= MAXPATHLEN) {
if (ndp->ni_pathlen > 1)
zfree(namei_zone, cp);
:..
:> > > $ cp foo bar
:> > > cp: foo is a directory (not copied)
:> > >
:> > > foo is certainly not a directory. The bug seems to be in fts.
:> >
:> > No, "foo" certainly _is_ a directory. It is precisely the same thing as
:> > ".".
:>
:> No, the empty pathname has been invalid and not an alias for "." since at
:> least the first version of POSIX.
:
:I didn't read the rest of the thread til later ;) The fact remains that
:FreeBSD interprets it as such in namei(), and is it not an undefined
:behavior according to POSIX?
:
:--
: Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Bruce Evans <[EMAIL PROTECTED]> wrote: > On Fri, 31 Aug 2001, Brian F. Feldman wrote: > > > Bruce Evans <[EMAIL PROTECTED]> wrote: > > > Here's an example of a standard utility being clueless about symlinks to > > > nothing: > > > > > > $ ln -s '' foo > > > $ cp foo bar > > > cp: foo is a directory (not copied) > > > > > > foo is certainly not a directory. The bug seems to be in fts. > > > > No, "foo" certainly _is_ a directory. It is precisely the same thing as > > ".". > > No, the empty pathname has been invalid and not an alias for "." since at > least the first version of POSIX. I didn't read the rest of the thread til later ;) The fact remains that FreeBSD interprets it as such in namei(), and is it not an undefined behavior according to POSIX? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
[Attribution deleted for clarity; see referenced messages in the archives.]
>> > $ ln -s '' foo
>> > $ cp foo bar
>> > cp: foo is a directory (not copied)
>> No, "foo" certainly _is_ a directory. It is precisely the same thing as
>> ".".
> No, the empty pathname has been invalid and not an alias for "." since at
> least the first version of POSIX.
"foo" is not the empty pathname. It is also not a directory; it is a
symbolic link. The pathname resolution rules require that references
to "foo" be indistinguishable from references to "." (outside of
those functions which are defined not to follow symbolic links).
XBDd7 says:
# If a symbolic link is encountered during pathname resolution, the
# behavior shall depend on whether the pathname component is at the
# end of the pathname and on the function being performed. If all of
# the following are true, then pathname resolution is complete:
[...]
# 3. The function is required to act on the symbolic link itself, or
#certain arguments direct that the function act on the symbolic
#link itself.
Since this is not true (see below), pathname resolution continues:
# In all other cases, the system shall prefix the remaining pathname,
# if any, with the contents of the symbolic link. If the combined
# length exceeds {PATH_MAX}, and the implementation considers this to
# be an error, errno shall be set to [ENAMETOOLONG] and an error
# indication shall be returned. Otherwise, the resolved pathname shall
# be the resolution of the pathname just created. If the resulting
# pathname does not begin with a slash, the predecessor of the first
# filename of the pathname is taken to be the directory containing the
# symbolic link.
The result of this construction rule is clearly an empty pathname.
The definition of ``pathname'' does not prohibit empty pathnames:
# [A pathname] has an optional beginning slash, followed by zero or
# more filenames separated by slashes. A pathname may optionally
# contain one or more trailing slashes. Multiple successive slashes
# are considered to be the same as one slash.
We seem to be in a region of undefined behavior here.
XCUd7 says (in defining `cp'):
# If source_file is a file of type symbolic link:
# * If neither the -R nor -r options were specified, cp shall take
# actions based on the type and contents of the file referenced by
# the symbolic link, and not by the symbolic link itself.
[...]
# For each source_file, the following steps shall be taken:
# 2. If source_file is of type directory, the following steps shall be
#taken:
# a. If neither the -R or -r options were specified, cp shall write a
#diagnostic message to standard error, do nothing more with
#source_file, and go on to any remaining files.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 31 Aug 2001, Brian F. Feldman wrote: > Bruce Evans <[EMAIL PROTECTED]> wrote: > > Here's an example of a standard utility being clueless about symlinks to > > nothing: > > > > $ ln -s '' foo > > $ cp foo bar > > cp: foo is a directory (not copied) > > > > foo is certainly not a directory. The bug seems to be in fts. > > No, "foo" certainly _is_ a directory. It is precisely the same thing as > ".". No, the empty pathname has been invalid and not an alias for "." since at least the first version of POSIX. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Bruce Evans <[EMAIL PROTECTED]> wrote: > On Fri, 15 Jun 2001, Steve O'Hara-Smith wrote: > > > On Fri, 15 Jun 2001 06:31:12 -0700 (PDT) > > David Wolfskill <[EMAIL PROTECTED]> wrote: > > > > DW> Indeed: it is my understanding that the "path name" interpretation is > > DW> an issue at the time of reference, not (necessarily) the time of > > DW> creation. It has, to the best of my knowledge, been valid to create a > > DW> symlink prior to a point when its target exists. > > > > It has been on evey platform I have ever used ln -s on. > > > > DW> One may well argue that this is "broken" in some way(s). Still, changing > > DW> it at this point could well be considered a POLA violation, at best. > > > > I would argue loud and long that changing that *would* be broken. There > > is never a guarantee (or even an implication) that a symlink points to a > > valid directory entry (think unmounted filesystems, NFS ...). I find it hard > > to imagine why creation time should be special in that regard. > > We are (or at least I am) talking about changing it to prevent links to a > string that can _never_ be a valid pathname. Fortunately, in POSIX there > is only one such string (the empty string). > > Here's an example of a standard utility being clueless about symlinks to > nothing: > > $ ln -s '' foo > $ cp foo bar > cp: foo is a directory (not copied) > > foo is certainly not a directory. The bug seems to be in fts. No, "foo" certainly _is_ a directory. It is precisely the same thing as ".". > cp is also broken for symlinks to valid pathnames for nonexistent files; > > $ rm -f foo > $ ln -s /nonesuch foo > $ cp foo bar > > This duplicates foo as a symlink, but should just fail. > > Bruce -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
On Sat, 23 Jun 2001, Matt Dillon wrote: > Ok, Bruce... the symlink patch has been sitting in my tree for a week > now. I am going to let you decide whether I should commit it or not. > If not, into the trash heap it goes. This is likely to be the only > way the problem will be solved since creating an empty symlink via > the 'ln -s' utility is perfect legal. So, in or out? In. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
Ok, Bruce... the symlink patch has been sitting in my tree for a week
now. I am going to let you decide whether I should commit it or not.
If not, into the trash heap it goes. This is likely to be the only
way the problem will be solved since creating an empty symlink via
the 'ln -s' utility is perfect legal. So, in or out?
-Matt
Index: kern/vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.38.2.2
diff -u -r1.38.2.2 vfs_lookup.c
--- kern/vfs_lookup.c 2001/05/20 12:11:57 1.38.2.2
+++ kern/vfs_lookup.c 2001/06/18 01:39:46
@@ -200,6 +200,12 @@
break;
}
linklen = MAXPATHLEN - auio.uio_resid;
+ if (linklen == 0) {
+ if (ndp->ni_pathlen > 1)
+ zfree(namei_zone, cp);
+ error = ENOENT;
+ break;
+ }
if (linklen + ndp->ni_pathlen >= MAXPATHLEN) {
if (ndp->ni_pathlen > 1)
zfree(namei_zone, cp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
> > So it seems to me the _use_ of a "" target symlink > > (in all but the final path component position) is exactly > > equivalent to the use of a "/" target symlink. When used in > > the final path component position, you get either the symlink > > or ENOENT. The POSIX excerpt Garrett quoted seems to match > > this. > > No, because the relevant slash is in the pathname resulting from > simple replacement of the full path prefix (/) > with the symlink's contents. Quoting Garrett's quote: IMHO the key point is the *resulting* remaining pathname after substitution. Normally one would simply prepend the contents before the , see if the resulting pathname starts with a '/', if so start the search at root else start the search at the parent of symlink. In any case any leading slashes are removed. In other words the bits are not kept separately from bits. This is a simpler implementation and seems to match what posix says. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
On Mon, 18 Jun 2001, Bakul Shah wrote: > > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23). > > I like it, except it seems to be incompatible with POSIX.1-200x. > > > ... [not what "not quite" applies to] > > Err... not quite. Given a path like > / > after the substitution of with its target, the > search must start at the root if target starts with > a "/". This is the most critical point. > So it seems to me the _use_ of a "" target symlink > (in all but the final path component position) is exactly > equivalent to the use of a "/" target symlink. When used in > the final path component position, you get either the symlink > or ENOENT. The POSIX excerpt Garrett quoted seems to match > this. No, because the relevant slash is in the pathname resulting from simple replacement of the full path prefix (/) with the symlink's contents. Quoting Garrett's quote: > I think I agree with your interpretation. Quoting from XBDd7, page > 101, lines 3153ff: > > # In all other cases, the system shall prefix the remaining pathname, > # if any, with the contents of the symbolic link. [...] [T]he > # resolved pathname shall be the resolution of the pathname just > # created. If the resulting pathname does not begin with a slash, the ^ > # predecessor of the first filename of the pathname is taken to be the > # directory containing the symbolic link. When the string symlink's contents is null, the resulting pathname is , and this always begins with a slash (since there wouldn't be a suffix without a slash). > This is surprising at first but hardly worth adding a > singularity (an exception). So IMHO for a "" target symlink The consequences of the standard are surprising at second :-). I wonder if surprising things also happen for suffixes beginning with 2 slashes? 2 slashes in the middle of the pathname are normally equivalent to a single slash, but if the quoted pathname resolution occurs before slash combination (I haven't read the standard carefully enough to know whether it does), then a null symlink pushes the double slash to the beginning of the pathname where it may have special meaning. A leading double slash also occurs when the symlink's contents is "/", and in this case the slashes can't be combined earlier. > This is not a big deal but I care about not having > unnecessary exceptions. Me too. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
< said: > In anycase, I can't imagine that POSIX actually intended null > symlinks to act in any particular way The standard specifies precisely how pathname resolution is supposed to behave. FreeBSD should conform to the standard, even if some of the consequences are somewhat unexpected. (At least the semantics are consistent!) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
:< said: : :>> > ./foo/ .// :>> > ./foo/bar .//bar :>> :>> No, because the ``resulting filename'' begins with a slash. : :> It seems resulting filename (pathname?) begins with "./" (not a slash). : :No, it doesn't. The ``resulting filename'' is "/" in the first case, :and "/bar" in the second case. Both begin with a slash, and so are :resolved relative to the root. There is no "./" involved anywhere in :the process. : :The value of the symbolic link is not somehow inserted into the path :being resolved. Once a symbolic link is encountered, pathname :resolution *starts over* with the last directory searched in the old :path used as the current working directory. : :-GAWollman Right, and since "" is an illegal path name... In anycase, I can't imagine that POSIX actually intended null symlinks to act in any particular way, and obviously they are cause for a great deal of confusion, and I don't know a single person who uses a null symlink on purpose. So I say we simply disallow them, hence the patch. If someone wants a symlink to point to / they can make it point to "/". If someone wants a symlink to point to the current directory they can make it point to ".". -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
< said: >> >./foo/ .// >> >./foo/bar .//bar >> >> No, because the ``resulting filename'' begins with a slash. > It seems resulting filename (pathname?) begins with "./" (not a slash). No, it doesn't. The ``resulting filename'' is "/" in the first case, and "/bar" in the second case. Both begin with a slash, and so are resolved relative to the root. There is no "./" involved anywhere in the process. The value of the symbolic link is not somehow inserted into the path being resolved. Once a symbolic link is encountered, pathname resolution *starts over* with the last directory searched in the old path used as the current working directory. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
On Mon, Jun 18, 2001 at 13:22:10 -0400, Garrett Wollman wrote: > < said: > > > Maybe it is just my bad English understanding, but it seems last two cases > > must be > > ./foo/ .// > > ./foo/bar .//bar > > No, because the ``resulting filename'' begins with a slash. It seems resulting filename (pathname?) begins with "./" (not a slash). I.e. I don't understand how "filename" can ever begin with "/", maybe they means "pathname" instead? "/" is not valid _filename_ component. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
< said: > Maybe it is just my bad English understanding, but it seems last two cases > must be > ./foo/ .// > ./foo/bar .//bar No, because the ``resulting filename'' begins with a slash. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23). > I like it, except it seems to be incompatible with POSIX.1-200x. > The bug that stat(2) on a null symlink classifies the target of the symlink > as a directory is caused by resolving the pathname to "" and then not > returning ENOENT in namei(). "" tends to be interpreted as "." unless > it is specially disallowed, and that's what happens here. "" is only > disallowed for the unresolved pathname. Since the bug is in namei(), it > affects all syscalls that deal with pathnames. E.g., you can open() > null symlinks; this is equivalent to opening ".". Err... not quite. Given a path like / after the substitution of with its target, the search must start at the root if target starts with a "/". So it seems to me the _use_ of a "" target symlink (in all but the final path component position) is exactly equivalent to the use of a "/" target symlink. When used in the final path component position, you get either the symlink or ENOENT. The POSIX excerpt Garrett quoted seems to match this. This is surprising at first but hardly worth adding a singularity (an exception). So IMHO for a "" target symlink used in _any place other than the final component_ it should be treated as if it points to just "/". Matt Dillon's patch seems to return ENOENT regardless of how a "" target symlink is used. This is not a big deal but I care about not having unnecessary exceptions. [Yes, I have read through this thread] -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
On Mon, Jun 18, 2001 at 11:53:59 -0400, Garrett Wollman wrote: > < said: > > > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23). > > I like it, except it seems to be incompatible with POSIX.1-200x. > > I think I agree with your interpretation. Quoting from XBDd7, page > 101, lines 3153ff: > > # In all other cases, the system shall prefix the remaining pathname, > # if any, with the contents of the symbolic link. [...] [T]he > # resolved pathname shall be the resolution of the pathname just > # created. If the resulting pathname does not begin with a slash, the > # predecessor of the first filename of the pathname is taken to be the > # directory containing the symbolic link. > > So, if we have a symbolic link ``foo'' with contents ``'' (i.e., the > empty string): > > PathnameResolves to > ./foo ./foo (i.e., the link itself), iff condition 3 > on lines 3151-2 is met; otherwise [ENOENT] > ./foo/ / > ./foo/bar /bar > Maybe it is just my bad English understanding, but it seems last two cases must be ./foo/ .// ./foo/bar .//bar per POSIX (i.e. "the predecessor of the first filename of the pathname is taken" since the symlink itself is filename too). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
< said: > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23). > I like it, except it seems to be incompatible with POSIX.1-200x. I think I agree with your interpretation. Quoting from XBDd7, page 101, lines 3153ff: # In all other cases, the system shall prefix the remaining pathname, # if any, with the contents of the symbolic link. [...] [T]he # resolved pathname shall be the resolution of the pathname just # created. If the resulting pathname does not begin with a slash, the # predecessor of the first filename of the pathname is taken to be the # directory containing the symbolic link. So, if we have a symbolic link ``foo'' with contents ``'' (i.e., the empty string): PathnameResolves to ./foo ./foo (i.e., the link itself), iff condition 3 on lines 3151-2 is met; otherwise [ENOENT] ./foo/ / ./foo/bar /bar -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
On Sun, 17 Jun 2001, Matt Dillon wrote:
> Ok, this patch should do it. For review. I've made it return ENOENT,
> which is the same error that is returned when you try to open an empty
> path (e.g. open("", ...)).
>
> (Note: This is unrelated to Bruce's second issue with 'cp' copying
> symlinks that don't exist, which is a cp-specific).
>
> If nobody has any objections I will commit this to -current on wednesday
> and MFC it next saturday.
>
> Index: vfs_lookup.c
> ===
> RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
> retrieving revision 1.38.2.2
> diff -u -r1.38.2.2 vfs_lookup.c
> --- vfs_lookup.c 2001/05/20 12:11:57 1.38.2.2
> +++ vfs_lookup.c 2001/06/18 01:39:46
> @@ -200,6 +200,12 @@
> break;
> }
> linklen = MAXPATHLEN - auio.uio_resid;
> + if (linklen == 0) {
> + if (ndp->ni_pathlen > 1)
> + zfree(namei_zone, cp);
> + error = ENOENT;
> + break;
> + }
> if (linklen + ndp->ni_pathlen >= MAXPATHLEN) {
> if (ndp->ni_pathlen > 1)
> zfree(namei_zone, cp);
NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
I like it, except it seems to be incompatible with POSIX.1-200x.
The bug that stat(2) on a null symlink classifies the target of the symlink
as a directory is caused by resolving the pathname to "" and then not
returning ENOENT in namei(). "" tends to be interpreted as "." unless
it is specially disallowed, and that's what happens here. "" is only
disallowed for the unresolved pathname. Since the bug is in namei(), it
affects all syscalls that deal with pathnames. E.g., you can open()
null symlinks; this is equivalent to opening ".".
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Heh. We came up with virtually the same patch at the same time! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Mon, Jun 18, 2001 at 03:40:28 +0200, Assar Westerlund wrote: > > What about this? > Matt's variant is better because return ENOENT _before_ NAMETOOLONG check. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
:
:On Sun, Jun 17, 2001 at 21:16:24 -0400, Garance A Drosihn wrote:
:>
:> When I say this, I assume that the only change to make is how any
:> 'open' or 'stat' call will handle null symlinks. If I am reading
:> Andrey correctly, there will be no change to the 'ln' command or
:> the symlink() system routine.
:
:Yes.
:
:> I generally prefer returning an error at the earliest point it can be
:> determined to be an error, and thus I think it IS worth it to make
:> this an error at open() or stat() time. I see no benefit in letting
:> those succeed only to have some strange error occur in later processing.
:
:Yes.
:
:--
:Andrey A. Chernov
Ok, this patch should do it. For review. I've made it return ENOENT,
which is the same error that is returned when you try to open an empty
path (e.g. open("", ...)).
(Note: This is unrelated to Bruce's second issue with 'cp' copying
symlinks that don't exist, which is a cp-specific).
If nobody has any objections I will commit this to -current on wednesday
and MFC it next saturday.
-Matt
Index: vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.38.2.2
diff -u -r1.38.2.2 vfs_lookup.c
--- vfs_lookup.c2001/05/20 12:11:57 1.38.2.2
+++ vfs_lookup.c2001/06/18 01:39:46
@@ -200,6 +200,12 @@
break;
}
linklen = MAXPATHLEN - auio.uio_resid;
+ if (linklen == 0) {
+ if (ndp->ni_pathlen > 1)
+ zfree(namei_zone, cp);
+ error = ENOENT;
+ break;
+ }
if (linklen + ndp->ni_pathlen >= MAXPATHLEN) {
if (ndp->ni_pathlen > 1)
zfree(namei_zone, cp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Garance A Drosihn <[EMAIL PROTECTED]> writes:
> I think that it's reasonable to just make it a specific error, and
> thus end this thread. No harm will come of making it a specific
> error on open, and it will address the problems mentioned earlier.
What about this?
/assar
Index: vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.45
diff -u -w -u -w -r1.45 vfs_lookup.c
--- vfs_lookup.c 2001/05/01 08:12:59 1.45
+++ vfs_lookup.c 2001/06/18 01:40:04
@@ -220,6 +220,12 @@
error = ENAMETOOLONG;
break;
}
+ if (linklen == 0) {
+ if (ndp->ni_pathlen > 1)
+zfree(namei_zone, cp);
+ error = ENOENT;
+ break;
+ }
if (ndp->ni_pathlen > 1) {
bcopy(ndp->ni_next, cp + linklen, ndp->ni_pathlen);
zfree(namei_zone, cnp->cn_pnbuf);
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 21:16:24 -0400, Garance A Drosihn wrote: > > When I say this, I assume that the only change to make is how any > 'open' or 'stat' call will handle null symlinks. If I am reading > Andrey correctly, there will be no change to the 'ln' command or > the symlink() system routine. Yes. > I generally prefer returning an error at the earliest point it can be > determined to be an error, and thus I think it IS worth it to make > this an error at open() or stat() time. I see no benefit in letting > those succeed only to have some strange error occur in later processing. Yes. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 18:00:06 -0700, Matt Dillon wrote: > > I think we can safely disallow path lookups going through empty symlinks > (i.e. at the time of the open(), lstat(), etc...), but we should not > go changing the "ln" command or the symlink() system call. This is exact the same thing as I suggest. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
At 2:28 PM -0700 6/17/01, Matt Dillon wrote: >:On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote: >:> It seems your argument to disallow null symlinks got somehow taken >:> as an argument to disallow all "invalid" symlinks then. >: >: >:To say it more clear: now I even not against ""-symlinks making ability, >:such strings are valid per POSIX after all, as already noticed in this >:discussion. I am against _resolving_ them to illegal "" name (and to "." >:in pathnames) which cause all errors that Bruce describe. >: >:-- >:Andrey A. Chernov > > This is a reasonable distinction to make. If someone actually > tried to open() a ""'d symlink an argument can be made to return > a specific error rather then trying to resolve it. I'm not sure > it's worth it, though. I think that it's reasonable to just make it a specific error, and thus end this thread. No harm will come of making it a specific error on open, and it will address the problems mentioned earlier. When I say this, I assume that the only change to make is how any 'open' or 'stat' call will handle null symlinks. If I am reading Andrey correctly, there will be no change to the 'ln' command or the symlink() system routine. Assuming this is true, is there any downside to making open() and stat() return an error for a null symlink? I generally prefer returning an error at the earliest point it can be determined to be an error, and thus I think it IS worth it to make this an error at open() or stat() time. I see no benefit in letting those succeed only to have some strange error occur in later processing. I do not care if this is or is not a security error, I am talking about saving someone time when debugging a side-effect of having a null symlink. I think that's my 2 cents on this issue, although later on I may find I'll want these 2 cents back and will contribute a different 2 cents. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:There is nothing to fix. Sometimes 'make install' instead 'make :installworld' typed can produce this. Of course, install procedure can be :complicated to make it foolprof, but I think the system must be fixed :instead to not resolve illegal names. It is not good idea to :produce workarounds of illegal names out of the system. : :-- :Andrey A. Chernov Ok, I took a look at Bruce's original example, which is: ln -s "" X If you were to then do something like "ls -la X/." you would get the root directory, and "ls -la X/" tries to list the current directory, and "cp -r X Y" tries to recursively copy the current directory, and fails. I think we can safely disallow path lookups going through empty symlinks (i.e. at the time of the open(), lstat(), etc...), but we should not go changing the "ln" command or the symlink() system call. In regards to Bruce's second example: $ rm -f foo $ ln -s /nonesuch foo $ cp foo bar Well, ok, if what the symlink points to does not exist 'cp' goes and copies the symlink instead. This seems harmless to me. I still don't see how any of this is a security issue, though. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 17:26:16 -0700, Matt Dillon wrote: > > If something in the build is creating empty symlinks under certain > circumstances, that something should be fixed. The problem isn't ln -s. There is nothing to fix. Sometimes 'make install' instead 'make installworld' typed can produce this. Of course, install procedure can be complicated to make it foolprof, but I think the system must be fixed instead to not resolve illegal names. It is not good idea to produce workarounds of illegal names out of the system. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 17:01:08 -0700, Matt Dillon wrote: > I'm sorry, I don't understand... what does this have to do with > an empty symlink verses a symlink containing something else? > 'rm' does not traverse symlinks. I not mean 'rm' literally. Read Bruce's comment about how fake names constructed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
: :On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: :> :> What cases? In all my years of programming I've never once 'accidently' :> created an empty symlink. : :See initial Bruce comments. Sometimes when 'make hierarchy' step is :missing, intermediate result of 'make install' can't be undone easily. I :hit this several times because my area (l10n) is symlink-rich. : :-- :Andrey A. Chernov :http://ache.pp.ru/ If something in the build is creating empty symlinks under certain circumstances, that something should be fixed. The problem isn't ln -s. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
: :On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: :> What cases? In all my years of programming I've never once 'accidently' :> created an empty symlink. : :The next example is fts-like activity - wrong final destination :appearse which is dangerous for 'rm'. I.e. in some situation you can :remove something like /kernel via specially constructed (by bad guy) empty :simlink. : :-- :Andrey A. Chernov :http://ache.pp.ru/ I'm sorry, I don't understand... what does this have to do with an empty symlink verses a symlink containing something else? 'rm' does not traverse symlinks. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: > What cases? In all my years of programming I've never once 'accidently' > created an empty symlink. The next example is fts-like activity - wrong final destination appearse which is dangerous for 'rm'. I.e. in some situation you can remove something like /kernel via specially constructed (by bad guy) empty simlink. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: > > What cases? In all my years of programming I've never once 'accidently' > created an empty symlink. See initial Bruce comments. Sometimes when 'make hierarchy' step is missing, intermediate result of 'make install' can't be undone easily. I hit this several times because my area (l10n) is symlink-rich. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:On Sun, Jun 17, 2001 at 14:28:40 -0700, Matt Dillon wrote: : :> rather then trying to resolve it. I'm not sure it's worth it, though. :> It just doesn't come up that often and there are a thousand other ways you :> can hogtie yourself in the system that takes less effort. : :It worth. It cause real 'make install' errors in some cases. : :-- :Andrey A. Chernov What cases? In all my years of programming I've never once 'accidently' created an empty symlink. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 14:28:40 -0700, Matt Dillon wrote: > rather then trying to resolve it. I'm not sure it's worth it, though. > It just doesn't come up that often and there are a thousand other ways you > can hogtie yourself in the system that takes less effort. It worth. It cause real 'make install' errors in some cases. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote: :> It seems your argument to disallow null symlinks got somehow taken :> as an argument to disallow all "invalid" symlinks then. : : :To say it more clear: now I even not against ""-symlinks making ability, :such strings are valid per POSIX after all, as already noticed in this :discussion. I am against _resolving_ them to illegal "" name (and to "." :in pathnames) which cause all errors that Bruce describe. : :-- :Andrey A. Chernov This is a reasonable distinction to make. If someone actually tried to open() a ""'d symlink an argument can be made to return a specific error rather then trying to resolve it. I'm not sure it's worth it, though. It just doesn't come up that often and there are a thousand other ways you can hogtie yourself in the system that takes less effort. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote: > It seems your argument to disallow null symlinks got somehow taken > as an argument to disallow all "invalid" symlinks then. To say it more clear: now I even not against ""-symlinks making ability, such strings are valid per POSIX after all, as already noticed in this discussion. I am against _resolving_ them to illegal "" name (and to "." in pathnames) which cause all errors that Bruce describe. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
It seems your argument to disallow null symlinks got somehow taken as an argument to disallow all "invalid" symlinks then. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 23:02:50 +1000, Bruce Evans wrote: > > So disallowing null symlinks would actually unbreak /etc/malloc.conf. > > Further debugging shows that the main bug is in the kernel. > stat(2) on a null symlink bogusly succeeds and classifies the symlink > as a directory. ln(1) just believes this so it rewrites > "ln -fs aj /etc/malloc.conf" to "ln -fs aj /etc/malloc.conf/aj". > The kernel then resolves /etc/malloc.conf/aj to /aj. And this should be fixed, as I say from the very beginning. (strangely, most people here mistreat null symlinks we discuss as non-null symlinks with non-existen targets) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Steve O'Hara-Smith" writes: > : I would argue loud and long that changing that *would* be broken. There > : is never a guarantee (or even an implication) that a symlink points to a > : valid directory entry (think unmounted filesystems, NFS ...). I find it hard > : to imagine why creation time should be special in that regard. > > And it would break /etc/malloc.conf! I'd have to agree 100% here. No, it (disallowing null symlinks, not disallowing symlinks to nonexistent files!!!) wouldn't break /etc/malloc.conf. "ln -fs '' /etc/malloc.conf" would simply fail after unlinking /etc/malloc.conf. There would then be no /etc/malloc.conf, which gives exactly the same behaviour as when /etc/malloc.conf is a null symlink. BTW, even ln(1) doesn't understand null symlinks: root$ cd /tmp # a safe place to clobber root$ ln -fs aj /etc/malloc.conf# my usual malloc.conf root$ ln -fs a /etc/malloc.conf# normal changes to it work root$ ln -fs '' /etc/malloc.conf# change it to null (works) root$ ln -fs aj /etc/malloc.conf# attempt to change it back root$ ls -l /etc/malloc.conf# change didn't work: lrwxr-xr-x 1 root wheel 0 Jun 17 22:15 /etc/malloc.conf -> root$ ls -l /aj # change clobbered root dir: lrwxr-xr-x 1 root wheel 2 Jun 17 22:31 /aj@ -> aj So disallowing null symlinks would actually unbreak /etc/malloc.conf. Further debugging shows that the main bug is in the kernel. stat(2) on a null symlink bogusly succeeds and classifies the symlink as a directory. ln(1) just believes this so it rewrites "ln -fs aj /etc/malloc.conf" to "ln -fs aj /etc/malloc.conf/aj". The kernel then resolves /etc/malloc.conf/aj to /aj. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
In message <[EMAIL PROTECTED]> "Steve O'Hara-Smith" writes: : I would argue loud and long that changing that *would* be broken. There : is never a guarantee (or even an implication) that a symlink points to a : valid directory entry (think unmounted filesystems, NFS ...). I find it hard : to imagine why creation time should be special in that regard. And it would break /etc/malloc.conf! I'd have to agree 100% here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:... :> :>True. It would break phk's malloc debugging features to disable this, :>for example. : :Not only that, but considerning that a symlink can point into a :different filesystem even in normal use, there is no simple way to :validate the valididty of the name. ... or be associated with a chroot situation and simply not resolve when accessed outside of the chroot. At BEST we had symlinks on the server that crossed NFS boundries on the client, for example. From the server's point of view they went off into empty space. Or a thousand other things. We should let this this thread die now. I think it's fairly clear that symlinks should not be messed with. cp's handling of symlinks is another, unrelated matter. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
In message <[EMAIL PROTECTED]>, Jordan Hubbard writes: >From: Matt Dillon <[EMAIL PROTECTED]> >Subject: Re: symlink(2) [Was: Re: tcsh.cat] >Date: Fri, 15 Jun 2001 22:01:47 -0700 (PDT) > >> Symlinks do not have to contain paths. People use them for all sorts >> of things so it would be totally inappropriate to put any sort of > >True. It would break phk's malloc debugging features to disable this, >for example. Not only that, but considerning that a symlink can point into a different filesystem even in normal use, there is no simple way to validate the valididty of the name. Consider this symlink: ln -s /my_FAT16_filesystem/foo:bar /tmp/blaf as a silly example of this. The only two real restrictions on symlinks are that they cannot contain NUL characters and that '/' means what '/' does in all filesystem naming on UNIX. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001 22:30:58 +1000 (EST) Bruce Evans <[EMAIL PROTECTED]> wrote: BE> cp always did this (except in the broken case of a broken symlink). POSIX BE> just clarifies it. From the FreeBSD manpage for cp(1): Ignore me, I think I must be going temporarily insane. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001, Steve O'Hara-Smith wrote: > On Sat, 16 Jun 2001 17:27:00 +1000 (EST) > Bruce Evans <[EMAIL PROTECTED]> wrote: > > > BE> > This is correct behaviour IMHO - why on earth should it fail. If I > BE> > copy a directory containing symlinks I don't want them do vanish just because > BE> > the target is unavailable. > BE> > BE> Because cp copies file contents, not file nodes (unless the -R flag is > BE> specified). This is clarified in current POSIX drafts. gnu cp gets > BE> this right. > > *WHAT*, let me get this straight POSIX drafts now suggest that cp *should* > turn a symlink into a file ? I truly dread to think how much that would break. cp always did this (except in the broken case of a broken symlink). POSIX just clarifies it. From the FreeBSD manpage for cp(1): -RIf source_file designates a directory, cp copies the directory and the entire subtree connected at that point. This option also causes symbolic links to be copied, rather than indirected through, ... Symbolic links are always followed unless the -R flag is set, in which case symbolic links are not followed, by default. ... > Please tell me I have the wrong end of the stick here, failing that someone > please tell me that FreeBSD will not follow this madness. You have the wrong end of the stick :-). > Hang on, the target of a symlink *is* the content of the symlink not the > content of the file that may or may not be at the target. At least it always used > to be that way. No. Wrong end... Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001 17:27:00 +1000 (EST) Bruce Evans <[EMAIL PROTECTED]> wrote: BE> > This is correct behaviour IMHO - why on earth should it fail. If I BE> > copy a directory containing symlinks I don't want them do vanish just because BE> > the target is unavailable. BE> BE> Because cp copies file contents, not file nodes (unless the -R flag is BE> specified). This is clarified in current POSIX drafts. gnu cp gets BE> this right. *WHAT*, let me get this straight POSIX drafts now suggest that cp *should* turn a symlink into a file ? I truly dread to think how much that would break. Please tell me I have the wrong end of the stick here, failing that someone please tell me that FreeBSD will not follow this madness. Hang on, the target of a symlink *is* the content of the symlink not the content of the file that may or may not be at the target. At least it always used to be that way. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001, Steve O'Hara-Smith wrote: > On Sat, 16 Jun 2001 14:34:07 +1000 (EST) > Bruce Evans <[EMAIL PROTECTED]> wrote: > BE> cp is also broken for symlinks to valid pathnames for nonexistent files; > BE> > BE> $ rm -f foo > BE> $ ln -s /nonesuch foo > BE> $ cp foo bar > BE> > BE> This duplicates foo as a symlink, but should just fail. > > This is correct behaviour IMHO - why on earth should it fail. If I > copy a directory containing symlinks I don't want them do vanish just because > the target is unavailable. Because cp copies file contents, not file nodes (unless the -R flag is specified). This is clarified in current POSIX drafts. gnu cp gets this right. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001 14:34:07 +1000 (EST) Bruce Evans <[EMAIL PROTECTED]> wrote: BE> We are (or at least I am) talking about changing it to prevent links to a BE> string that can _never_ be a valid pathname. Fortunately, in POSIX there BE> is only one such string (the empty string). Maybe, but it seems a harmless special case to me, and others seem to find it useful. BE> Here's an example of a standard utility being clueless about symlinks to BE> nothing: BE> BE> $ ln -s '' foo BE> $ cp foo bar BE> cp: foo is a directory (not copied) That *is* broken, it should make bar a symlink to '' IMHO. BE> cp is also broken for symlinks to valid pathnames for nonexistent files; BE> BE> $ rm -f foo BE> $ ln -s /nonesuch foo BE> $ cp foo bar BE> BE> This duplicates foo as a symlink, but should just fail. This is correct behaviour IMHO - why on earth should it fail. If I copy a directory containing symlinks I don't want them do vanish just because the target is unavailable. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
From: Matt Dillon <[EMAIL PROTECTED]> Subject: Re: symlink(2) [Was: Re: tcsh.cat] Date: Fri, 15 Jun 2001 22:01:47 -0700 (PDT) > Symlinks do not have to contain paths. People use them for all sorts > of things so it would be totally inappropriate to put any sort of True. It would break phk's malloc debugging features to disable this, for example. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:... :> It has been on evey platform I have ever used ln -s on. :> :> DW> One may well argue that this is "broken" in some way(s). Still, changing :> DW> it at this point could well be considered a POLA violation, at best. :> :> I would argue loud and long that changing that *would* be broken. There :> is never a guarantee (or even an implication) that a symlink points to a :> valid directory entry (think unmounted filesystems, NFS ...). I find it hard :> to imagine why creation time should be special in that regard. : :We are (or at least I am) talking about changing it to prevent links to a :string that can _never_ be a valid pathname. Fortunately, in POSIX there :is only one such string (the empty string). Symlinks do not have to contain paths. People use them for all sorts of things so it would be totally inappropriate to put any sort of restriction on the data you can store as a symlink. For example, symlink() is the *ONLY* system call that is atomic across all flavors of NFS. There is absolutely nothing wrong with creating a symlink that is "". -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 15 Jun 2001, Steve O'Hara-Smith wrote: > On Fri, 15 Jun 2001 06:31:12 -0700 (PDT) > David Wolfskill <[EMAIL PROTECTED]> wrote: > > DW> Indeed: it is my understanding that the "path name" interpretation is > DW> an issue at the time of reference, not (necessarily) the time of > DW> creation. It has, to the best of my knowledge, been valid to create a > DW> symlink prior to a point when its target exists. > > It has been on evey platform I have ever used ln -s on. > > DW> One may well argue that this is "broken" in some way(s). Still, changing > DW> it at this point could well be considered a POLA violation, at best. > > I would argue loud and long that changing that *would* be broken. There > is never a guarantee (or even an implication) that a symlink points to a > valid directory entry (think unmounted filesystems, NFS ...). I find it hard > to imagine why creation time should be special in that regard. We are (or at least I am) talking about changing it to prevent links to a string that can _never_ be a valid pathname. Fortunately, in POSIX there is only one such string (the empty string). Here's an example of a standard utility being clueless about symlinks to nothing: $ ln -s '' foo $ cp foo bar cp: foo is a directory (not copied) foo is certainly not a directory. The bug seems to be in fts. cp is also broken for symlinks to valid pathnames for nonexistent files; $ rm -f foo $ ln -s /nonesuch foo $ cp foo bar This duplicates foo as a symlink, but should just fail. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 15 Jun 2001 06:31:12 -0700 (PDT) David Wolfskill <[EMAIL PROTECTED]> wrote: DW> Indeed: it is my understanding that the "path name" interpretation is DW> an issue at the time of reference, not (necessarily) the time of DW> creation. It has, to the best of my knowledge, been valid to create a DW> symlink prior to a point when its target exists. It has been on evey platform I have ever used ln -s on. DW> One may well argue that this is "broken" in some way(s). Still, changing DW> it at this point could well be considered a POLA violation, at best. I would argue loud and long that changing that *would* be broken. There is never a guarantee (or even an implication) that a symlink points to a valid directory entry (think unmounted filesystems, NFS ...). I find it hard to imagine why creation time should be special in that regard. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
symlink(2) [Was: Re: tcsh.cat]
>Date: Fri, 15 Jun 2001 22:57:56 +1000 (EST) >From: Bruce Evans <[EMAIL PROTECTED]> >> Maybe we need to fix symlink(2) then ? >Maybe, but this doesn't seem to be permitted by POSIX.1-200x: >P>int symlink(const char *path1, const char *path2); >P>... >P>The string pointed to by path1 shall be treated only as a character >P>string and shall not be validated as a pathname. >symlink.2 is fuzzier and can be read as reqiring that the first arg is >a (valid) "path name". >B>int >B>symlink(const char *name1, const char *name2); >B>... >B>A symbolic link name2 is created to name1 (name2 is the name of the file >B>created, name1 is the string used in creating the symbolic link). Either >B>name may be an arbitrary path name; the files need not be on the same >B>file system. Indeed: it is my understanding that the "path name" interpretation is an issue at the time of reference, not (necessarily) the time of creation. It has, to the best of my knowledge, been valid to create a symlink prior to a point when its target exists. One may well argue that this is "broken" in some way(s). Still, changing it at this point could well be considered a POLA violation, at best. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
