Minutes of the 1 May 2008 Teleconference Austin-429 Page 1 of 1 Submitted by Andrew Josey, The Open Group. May 2 , 2008 Attendees Andrew Josey, The Open Group Don Cragun , Sun, PASC OR Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Apologies Ulrich Drepper, Red Hat The purpose of the call was primarily to review the comments on the Draft 5 review (sanity draft). Three ERNs were reviewed. +Sanity draft comments ERN 1 Accept ERN 2 Accept ERN 3 Accept The editors will prepare d5.1 with the above ERNs applied and circulate to IEEE and ISO for the final balloting. Action: Editors prepare D5.1, target date May 15 2008. +Disposition against the ISO ballot We have an outstanding action to respond to the ISO FCD ballot. Andrew will prepare a disposition of comments. This should address the US, Canada and UK comments explicitly. We have applied all the US comments (and therefore Canada's) exactly as described. As requested by the UK, in addition to the US comments the following interpretations are as follows: 1003.1-2001 #092 1003.1-2001 #016 1003.1-2001 #123 1003.1-2001 #124 1003.1-2001 #125 1003.1-2001 #126 1003.1-2001 #127 1003.1-2001 #128 1003.1-2001 #129 1003.1-2001 #130 1003.1-2001 #131 1003.1-2001 #132 1003.1-2001 #133 1003.1-2001 #134 1003.1-2001 #135 1003.1-2001 #136 1003.1-2001 #137 1003.1-2001 #138 1003.1-2001 #139 1003.1-2001 #140 1003.1-2001 #141 1003.1-2001 #142 1003.1-2001 #143 1003.1-2001 #144 1003.1-2001 #145 1003.1-2001 #146 1003.1-2001 #147 1003.1-2001 #148 1003.1-2001 #149 1003.1-2001 #150 1003.1-2001 #151 1003.1-2001 #152 1003.1-2001 #153 1003.1-2001 #154 1003.1-2001 #155 1003.1-2001 #156 1003.1-2001 #157 1003.1-2001 #158 1003.1-2001 #159 1003.1-2001 #160 1003.1-2001 #161 1003.1-2001 #162 1003.1-2001 #163 1003.1-2001 #164 1003.1-2001 #165 1003.1-2001 #166 1003.1-2001 #167 1003.1-2001 #168 1003.1-2001 #169 1003.1-2001 #170 1003.1-2001 #171 1003.1-2001 #172 1003.1-2001 #173 1003.1-2001 #174 1003.1-2001 #175 1003.1-2001 #176 1003.1-2001 #177 1003.1-2001 #178 1003.1-2001 #179 1003.1-2001 #180 1003.1-2001 #181 1003.1-2001 #182 1003.1-2001 #183 1003.1-2001 #184 1003.1-2001 #185 1003.1-2001 #186 1003.1-2001 #187 1003.1-2001 #188 1003.1-2001 #189 1003.1-2001 #190 1003.1-2001 #191 1003.1-2001 #192 1003.1-2001 #193 1003.1-2001 #194 1003.1-2001 #195 1003.1-2001 #196 1003.1-2001 #197 1003.1-2001 #198 1003.1-2001 #199 1003.1-2001 #200 1003.1-2001 #201 1003.1-2001 #202 1003.1-2001 #203 1003.1-2001 #204 1003.1-2001 #205 1003.1-2001 #206 1003.1-2001 #207 1003.1-2001 #208 1003.1-2001 #209 1003.1-2001 #210 Detailed text of the interpretations are available at: https://www.opengroup.org/austin/interps/ In addition for coordination with the IEEE ballot subsequent to draft 3 the following editorial changes were made XSHbug2 ERN 145 XSHbug2 ERN 193 XSHbug2 ERN 219 XSHbug2 ERN 220 XSHbug2 ERN 227 See http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt XCUbug2 ERN 135 XCUbug2 ERN 139 XCUbug2 ERN 141 XCUbug2 ERN 148 XCUbug2 ERN 149 XCUbug2 ERN 164 XCUbug2 ERN 171 XCUbug2 ERN 174 http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt XBDbug2 ERN 53 See http://www.opengroup.org/austin/aardvark/latest/xbdbug2.txt XRATbug2 ERN 8 See http://www.opengroup.org/austin/aardvark/latest/xratbug2.txt Action: Andrew to draft a DoC and then after review to send that to Sally ** Aardvark We picked up on the 2004 aardvark reports. XSH ERN 237 section 11.1.11 Accept as marked below Send down the interps track (ambiguous case) Change the text to: "The last process to close a terminal device file shall cause any output to be sent to the device and shall cause any input to be discarded." XSH ERN 238 fputc SIGXFSZ OPEN Leave open for now as we need to enumerate the set of changes. Action: Don to look at this and propose a set of changes. XSH ERN 239 fwide Accept Send down the interps track , the standard is silent on the issue XSH ERN 240 putenv environ OPEN We feel there is some history here, and decided to leave this open until Ulrich is on the call XSH ERN 241 raise async safety Accept Send down the interps track, the standard is unclear XCU ERN 178 ln Reject The response is based on the email from Geoff: > ABSTRACT > > XCU page 549 lines 21195-7 > i. not only allows but *requires* ln -s basename target_dir to create a symlink which points to itself. (Likewise for > ln -s basename target_dir/basename and ln -s basename/ target_dir/basename.) > ii. prohibits ln from writing an error message when it creates a symlink which points to itself (i). > > A symlink which points to itself is a bug which tries to cause an infinite loop when used. A loop only occurs if an attempt is made to _follow_ the link. Other uses of symbolic links are possible which do not follow the link. The standard explicitly allows symbolic links to contain arbitrary strings; they do not need to be valid pathnames. Some applications make use of this feature to store information in symbolic links. For example firefox creates this file when running: $ readlink .mozilla/firefox/def*/lock 10.9.9.1:+29143 It is entirely possible that applications exist which make use of this feature in such a way that occasionally the contents of a created symbolic link may happen to be the same as its filename. Preventing the creation of such links would break the application. > Ln has several idiosyncrasies which make such bugs especially likely. It is true that novice users often get confused by the difference between ln source target and ln -s source target in the handling of "source", and this can lead to the creation of symlinks that point to themselves. However, this is by no means the only way that such links can be created. One obvious way is by renaming: $ ln -s file1 file2 $ rm -f file1 $ mv file2 file1 $ ls file1 ls: file1: Too many levels of symbolic links Another way is by copying a directory: $ mkdir dir1 $ ln -s ../dir2/link dir1/link $ cp -RP dir1 dir2 $ ls dir2/link ls: dir2/link: Too many levels of symbolic links It could also happen through the use of "pax -r -s/file1/file2/" Of course, any application could use the symlink() function to create such links (or symlink() followed by rename()). > Proposal A revises ln's Description to prevent these bugs without otherwise affecting ln's behavior or functionality. Proposals > B-C add Examples and Rationale, respectively. > > > DEFINITIONS > > Throughout this report, the definitions, XCU page 550 lines 21213-7 are used verbatim: > source_file is a pathname of a file to be linked, and > target_dir is a pathname of an *existing* directory in which the new directory entries are created > > > PROBLEM DESCRIPTION > > Example 1. The commands: > > cd /etc > ln fstab X11/ > > create a hardlink called /etc/X11/fstab as a synonym for /etc/fstab. When creating hardlinks, ln resolves all its arguments. Here, > both of ln's arguments are relative paths, which ln resolves relative to working directory /etc. > > Example 2. The commands: > > cd /etc > ln -s fstab X11/ > > create a symlink called /etc/X11/fstab whose pointer is the string "fstab". This symlink points to itself, not to /etc/fstab as > might be expected from Example 1. > The problem here is the "as might be expected from Example 1" part, not the behaviour of ln. If a user executes such a command, it is a user error due to a lack of understanding of how "ln -s" works. A user who understands "ln -s" would not make this error and would execute the proper command: cd /etc ln -s ../fstab X11/ or perhaps: cd /etc/X11 ln -s ../fstab . > > Ln has several idiosyncrasies which make bugs like Example 2 especially likely: > > a. Ln handles pathnames in an unusual way. Most Unix utilities and shells resolve all relative paths relative to the working > directory, but ln does not. > > b. Ln handles pathnames in an inconsistent way: > > 1. When ln creates hardlinks, all relative paths are resolved in the usual way (relative to the working directory) (Example > 1), but not when ln creates symlinks (Example 2). There only seems to be an inconsistency when thinking about source_file in "ln -s source_file target_dir" as if it were a pathname. In fact it is an arbitrary string and is not resolved at all (when the link is created). It may be worth altering the wording on the ln page so that this distinction is made clearer. Or at least add a statement like the one on the symlink() page, "The string pointed to by path1 shall be treated only as a character string and shall not be validated as a pathname." > > 2. Even when ln creates symlinks, a relative path is resolved in the usual way (relative to the working directory) if it's > the final argument but not if it's a source_file (Example 2). Again, for ln -s, source_file is not a relative path, it is an arbitrary string. > c. Ln writes no error message when it creates a symlink which points to itself. An error message only occurs later, when the > symlink is used (and attempts to cause an infinite loop). This is exactly as it should be. Apart from silly mistakes by novice users, or accidents arising from renaming files, copying directories, etc., if such a symlink is created it is because it is being used to hold an arbitrary string and is not intended to be followed. Trying to follow the link produces an error, alerting the user to the fact that they should not have tried to follow it. An error would also occur if the target of the symlink does not exist. Again, the fault is with the user trying to follow a link which is not meant to be followed, not with the original creation of the link. XCU ERN 179 withdrawn by the submitter XCU ERN 180 pax OPEN * Interpretations Andrew will check the interps status to see if any should be finalized. Next meeting ------------ The next call will be May 15th at 16:00 UK time. to carry on with the aardvark An IRC channel will be available for the meeting irc://irc.freestandards.org #austin irc://irc.freestandards.org/austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic