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: 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]
[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]
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
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 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
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]
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: 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])
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])
On Mon, 18 Jun 2001 15:40:23 +1000 (EST), Bruce Evans [EMAIL PROTECTED] 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 Mon, Jun 18, 2001 at 13:22:10 -0400, Garrett Wollman wrote: On Mon, 18 Jun 2001 20:59:45 +0400, Andrey A. Chernov [EMAIL PROTECTED] 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])
On Mon, 18 Jun 2001 21:35:17 +0400, Andrey A. Chernov [EMAIL PROTECTED] 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, 18 Jun 2001 21:35:17 +0400, Andrey A. Chernov [EMAIL PROTECTED] 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])
On Mon, 18 Jun 2001 10:46:27 -0700 (PDT), Matt Dillon [EMAIL PROTECTED] 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: tcsh.cat
On Fri, 15 Jun 2001 23:33:07 +1000 (EST), Bruce Evans [EMAIL PROTECTED] said: Here's an example of a complication: what is the semantics of /tmp/foo/bar where foo is a symlink to ? I think the pathname resolves to /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't point anywhere. But this is at least consistent with the historic (pre-POSIX) behavior where the filename is equivalent to .. Your spell checker didn't seem to catch your mis-spelling of hysteric :I -GAWollman -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! 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]
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 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]
: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 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 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 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 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. : :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. : :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 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 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]
: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]
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]
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]
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]
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: 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]
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]
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 17:27:00 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: BEThis 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 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 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]
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: tcsh.cat
In message [EMAIL PROTECTED] Karsten W. Rohrbach writes: : lrwxrwxr-x 1 david wheel 13 Jun 15 06:40 .netscape/lock - 1.0.0.127:6= : 12 : this is actually more performant than writing ascii text into a file and : checking the file by opening and parsing it. you simply do not have to : fopen() and stuff. very convenient ;-) ls -l /etc/malloc.conf :-) Warnr 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: tcsh.cat
On Fri, Jun 15, 2001 at 13:15:04 +1000, Bruce Evans wrote: Related bugs: - symlink(2) is happy to create a symlink to the empty pathname although empty pathnames are invalid. Maybe we need to fix symlink(2) then ? -- 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: tcsh.cat
On Fri, 15 Jun 2001, Andrey A. Chernov wrote: On Fri, Jun 15, 2001 at 13:15:04 +1000, Bruce Evans wrote: Related bugs: - symlink(2) is happy to create a symlink to the empty pathname although empty pathnames are invalid. Maybe we need to fix symlink(2) then ? Maybe, but this doesn't seem to be permitted by POSIX.1-200x: Pint symlink(const char *path1, const char *path2); P... PThe string pointed to by path1 shall be treated only as a character Pstring 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. Bint Bsymlink(const char *name1, const char *name2); B... BA symbolic link name2 is created to name1 (name2 is the name of the file Bcreated, name1 is the string used in creating the symbolic link). Either Bname may be an arbitrary path name; the files need not be on the same Bfile system. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
PThe string pointed to by path1 shall be treated only as a character Pstring and shall not be validated as a pathname. I have heard on several occasions of peope using symlink(2) to atomically store some small piece of information for locking purposes. (Symlink was more reliably atomic over NFS than other methods.) So it is possible that changing this might break something. -- Richard 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: Pint symlink(const char *path1, const char *path2); P... PThe string pointed to by path1 shall be treated only as a character Pstring 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. Bint Bsymlink(const char *name1, const char *name2); B... BA symbolic link name2 is created to name1 (name2 is the name of the file Bcreated, name1 is the string used in creating the symbolic link). Either Bname may be an arbitrary path name; the files need not be on the same Bfile 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
Re: tcsh.cat
On Fri, 15 Jun 2001, Richard Tobin wrote: PThe string pointed to by path1 shall be treated only as a character Pstring and shall not be validated as a pathname. I have heard on several occasions of peope using symlink(2) to atomically store some small piece of information for locking purposes. (Symlink was more reliably atomic over NFS than other methods.) So it is possible that changing this might break something. Yes. /etc/malloc.conf is another example (for non-locking purposes). Here's an example of a complication: what is the semantics of /tmp/foo/bar where foo is a symlink to ? I think the pathname resolves to /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't point anywhere. Similarly, /tmp/bar/foo resolves to /tmp/bar/ and then to /tmp/bar (/tmp/bar must be a directory to get that far). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
Date: Fri, 15 Jun 2001 23:33:07 +1000 (EST) From: Bruce Evans [EMAIL PROTECTED] I have heard on several occasions of peope using symlink(2) to atomically store some small piece of information for locking purposes. (Symlink was more reliably atomic over NFS than other methods.) So it is possible that changing this might break something. Yes. /etc/malloc.conf is another example (for non-locking purposes). And another: dhcp-133[1] ls -l .netscape/lock lrwxrwxr-x 1 david wheel 13 Jun 15 06:40 .netscape/lock - 1.0.0.127:612 :-}, david (making no claims about what is good practice, here) -- 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
Re: tcsh.cat
Andrey A. Chernov([EMAIL PROTECTED])@2001.06.15 16:02:50 +: On Fri, Jun 15, 2001 at 13:15:04 +1000, Bruce Evans wrote: Related bugs: - symlink(2) is happy to create a symlink to the empty pathname although empty pathnames are invalid. Maybe we need to fix symlink(2) then ? no, it will probably break some obfuscated code that stores state in symlinks (yes, this is done on some systems). i never encountered any unix that checked for existance of the symlink's target in symlink(2). ln perhaps should do it but override this specific behaviour then with -f. have fun, /k -- The new glue is, unfortunately, ignored by recent versions of the BIND cache; the detailed technical explanation for this is that the BIND company is a bunch of idiots. --DJB discussing yet another BIND failing KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 PGP signature
Re: tcsh.cat
David Wolfskill([EMAIL PROTECTED])@2001.06.15 06:53:27 +: And another: dhcp-133[1] ls -l .netscape/lock lrwxrwxr-x 1 david wheel 13 Jun 15 06:40 .netscape/lock - 1.0.0.127:612 :-}, david (making no claims about what is good practice, here) this is actually more performant than writing ascii text into a file and checking the file by opening and parsing it. you simply do not have to fopen() and stuff. very convenient ;-) /k -- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. --Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 PGP signature
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
Re: tcsh.cat
On Fri, 15 Jun 2001 23:33:07 +1000 (EST), Bruce Evans [EMAIL PROTECTED] said: Here's an example of a complication: what is the semantics of /tmp/foo/bar where foo is a symlink to ? I think the pathname resolves to /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't point anywhere. But this is at least consistent with the historic (pre-POSIX) behavior where the filename is equivalent to .. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
On Fri, 15 Jun 2001 22:57:56 +1000 (EST), Bruce Evans [EMAIL PROTECTED] said: Maybe, but this doesn't seem to be permitted by POSIX.1-200x: The response I got to a similar question about symbolic links suggests that the definition of ``path name resolution'' is supposed to be the final word on the meaning and interpretation of symbolic links. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
On Fri, Jun 15, 2001 at 15:53:10 -0400, Garrett Wollman wrote: On Fri, 15 Jun 2001 23:33:07 +1000 (EST), Bruce Evans [EMAIL PROTECTED] said: Here's an example of a complication: what is the semantics of /tmp/foo/bar where foo is a symlink to ? I think the pathname resolves to /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't point anywhere. But this is at least consistent with the historic (pre-POSIX) behavior where the filename is equivalent to .. POSIX explicitly disallow filenames everywhere. I think it should be so for symlinks 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: tcsh.cat
On Sat, 16 Jun 2001 01:24:19 +0400, Andrey A. Chernov [EMAIL PROTECTED] said: POSIX explicitly disallow filenames everywhere. I think it should be so for symlinks too. But it doesn't, and that's the end of it for at least another five years. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
On Fri, Jun 15, 2001 at 02:08:03PM +0100, Richard Tobin wrote:
PThe string pointed to by path1 shall be treated only as a character
Pstring and shall not be validated as a pathname.
I have heard on several occasions of peope using symlink(2) to
atomically store some small piece of information for locking purposes.
Netscape for instance, uses ~/.netscape/lock as a symlink to the IP and
PID that it's running on:
uniq{sethk}254% ll ~/.netscape/lock
lrwxr-xr-x 1 sethk wheel 20 Jun 15 15:34 /home/sethk/.netscape/lock
- 204.216.28.154:27906
--
|| Seth Kingsley || Platforms Lab Opps || [EMAIL PROTECTED] ||
PGP signature
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]
:... : 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]
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
tcsh.cat
Hi folks I'm having a prob with tcsh.cat when performing a a make install after a buildworld and can't seem to shrug it off and or find a reason to it's occurance does any one know of a fix as I cant go any further :( /bin/tcsh - /bin/csh install -c -o root -g wheel -m 444 csh.1.gz /usr/share/man/man1 /usr/share/man/man1/tcsh.1.gz - /usr/share/man/man1/csh.1.gz === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat install: /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat: No such file or directory *** Error code 71 Stop in /usr/src/bin/csh/nls/finnish. *** Error code 1 Stop in /usr/src/bin/csh/nls. *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cheers Adrian [EMAIL PROTECTED] __ _ / /___ ___ / __ ) ___// __ \ / /_ / ___/ _ \/ _ \/ __ \__ \/ / / / / __/ / / / __/ __/ /_/ /__/ / /_/ / /_/ /_/ \___/\___/_//_/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
On Thu, Jun 14, 2001 at 22:53:25 +0100, Adrian Browne wrote: Hi folks I'm having a prob with tcsh.cat when performing a a make install after a buildworld and can't seem to shrug it off and or find a reason to it's occurance does any one know of a fix as I cant go any further :( It seems that 'make hierarchy' step is missing somehow, so required directories are not created. 'make world' definitely create them. Probably you run 'make install' instead of 'make installworld' which create them too. /bin/tcsh - /bin/csh install -c -o root -g wheel -m 444 csh.1.gz /usr/share/man/man1 /usr/share/man/man1/tcsh.1.gz - /usr/share/man/man1/csh.1.gz === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat install: /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat: No such file or directory *** Error code 71 Stop in /usr/src/bin/csh/nls/finnish. *** Error code 1 Stop in /usr/src/bin/csh/nls. *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cheers Adrian [EMAIL PROTECTED] __ _ / /___ ___ / __ ) ___// __ \ / /_ / ___/ _ \/ _ \/ __ \__ \/ / / / / __/ / / / __/ __/ /_/ /__/ / /_/ / /_/ /_/ \___/\___/_//_/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- 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: tcsh.cat
On Fri, 15 Jun 2001, Andrey A. Chernov wrote: On Thu, Jun 14, 2001 at 22:53:25 +0100, Adrian Browne wrote: Hi folks I'm having a prob with tcsh.cat when performing a a make install after a buildworld and can't seem to shrug it off and or find a reason to it's occurance does any one know of a fix as I cant go any further :( It seems that 'make hierarchy' step is missing somehow, so required directories are not created. 'make world' definitely create them. Probably you run 'make install' instead of 'make installworld' which create them too. /bin/tcsh - /bin/csh install -c -o root -g wheel -m 444 csh.1.gz /usr/share/man/man1 /usr/share/man/man1/tcsh.1.gz - /usr/share/man/man1/csh.1.gz === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat install: /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat: No such file or directory *** Error code 71 There is a bug somewhere, possibly related to error handling for installworld when the hierarchy is incomplate, that causes the tcsh.cat symlink to point to the empty pathname. ISTR that once you have such a symlink for tcsh.cat, installworld is unable to recover even when the hierarchy is fixed (I used the easy fix of removing the symlink). Related bugs: - symlink(2) is happy to create a symlink to the empty pathname although empty pathnames are invalid. - many utilities are confused by symlinks to the empty pathname. ISTR that one error mode is to blindly append a slash to pathnames, so gets transformed to the completely different pathname /. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
