Anonymous | Login | 2023-10-02 01:43 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001013 | [1003.1(2008)/Issue 7] Shell and Utilities | Editorial | Clarification Requested | 2015-12-16 16:48 | 2016-10-13 16:08 | ||
Reporter | joerg | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Rejected | ||||
Status | Closed | ||||||
Name | Jörg Schilling | ||||||
Organization | |||||||
User Reference | |||||||
Section | Utilities | ||||||
Page Number | 2530 + 3093 | ||||||
Line Number | 81644-81646 + 103207-103208 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | |||||||
Summary | 0001013: cd and pwd should not default to -L | ||||||
Description |
When the Bourne Shell was enhanced by AT&T for SVr4 in 1989, this was intentionally not done in a way that is 100% compatible to ksh88 with respect to cd and pwd behavior. While ksh88 defaults to -L, the Bourne Shell only supports the "physical" mode that is in effect if ksh88 is called with -P. I am currently working on making the Bourne Shell POSIX compliant but for consistency do not like to change the default behavior of cd and pwd while adding support for -L and -P. We should not demand a default behavior that is less useful than the default from the Bourne Shell but rather leave it to the implementor which default to chose. |
||||||
Desired Action |
Change page 2503 line 81644-81646 from: If both −L and −P options are specified, the last of these options shall be used and all others ignored. If neither −L nor −P is specified, it is implementation specific which default is chosen. Change page 3093 line 103207-103208 from: If both −L and −P are specified, the last one shall apply. If neither −L nor −P is specified, the pwd utility shall behave as if −L had been specified. to: If both −L and −P are specified, the last one shall apply. If neither −L nor −P is specified, it is implementation specific which default is chosen. |
||||||
Tags | No tags attached. | ||||||
Attached Files | |||||||
|
![]() |
|||||||
|
![]() |
|
(0002979) shware_systems (reporter) 2015-12-16 23:00 edited on: 2015-12-16 23:01 |
Such a choice is better described as a known extension, imo. Scripts written to be conforming now expecting -L may break, so in strict mode that should still hold. In non-strict mode the -P can be the implementation-defined default as the extension. The alternative is requiring all existing scripts to add -L or -P to all uses of cd and pwd to be considered reliably conforming. As is, only Bourne scripts need -P added. |
(0002980) joerg (reporter) 2015-12-17 10:48 edited on: 2015-12-21 15:41 |
I am not sure whether there is a better way to document this. The problem is that during the past 26 years, the conflicting behavior did coexist and people seem to be able to live with it. On the other side, the Bourne Shell currently only implements what you get on ksh via "cd/pwd -P". I am willing to add support for -L and -P to the Burne Shell, but I am not willing to introduce less safe default behavior at the same time. |
(0002984) user229 2015-12-17 14:03 |
I'm not sure if much weight should be given to "during the past 26 years, the conflicting behavior did coexist and people seem to be able to live with it." That could mean several things. Maybe most people use only one shell, or only shells that behave the same way, and individually got used to that shell's behavior. Or most people don't work with symbolic links, or paths containing something/../something-else, very often. Personally I prefer the P-behavior (because it matches how names are resolved by non-shell processes), but consistency is probably more important for the standard. Your last note is the first time in this page you've referred to the L-behavior as "less safe", would you care to explain why this is so? |
(0002985) a brouwer (reporter) 2015-12-17 16:06 |
The -L is an ugly hack, introduced at a time when there was no proper mount support, and should be deprecated today. It is ugly, maybe a security risk, because it introduces the situation where shell and kernel interpret pathnames differently. As in % ls .. a b c garbage temp % cd .. % rm g* t* rm: cannot remove t*: No such file or directory |
(0002987) shware_systems (reporter) 2015-12-17 16:19 |
For cd I see the lack of safety stems from when a path component backtracked into by a '..' element is a symbolic link's new root and this has fewer elements than succeeding '..' elements then resolution eventually attempts to access above root, with -P, and this won't be evident just looking at what's entered. Example, if baz is a symbolic link to '/', evaluating '/foo/bar/baz/../../fum' looks like it should access '/foo/fum/' but will produce an error when the first '..' is evaluated. With -L, deferring symbolic link resolution until after the '..' elements are resolved just on the path text entered may skip over an access restriction check of a symbolically linked to directory. It may even redirect accesses from a mounted device to the device that represents the root of the logical file system. For the above, bar may be a 'no search' directory, yet the only checks will be of foo and fum when 'bar/baz/../../' is deleted. Both options are problematic when links are present, essentially. For left-to-right evaluation the -P is 'safer' in that both hard and symbolic link elements must all pass the access checks. I'd prefer an additional -N option that aborts if a named element entered before any .. elements or recursed into is a symbolic link, to be consistent with the interfaces that allow SYMLINK_NOFOLLOW as a flag. |
(0003187) joerg (reporter) 2016-04-29 09:18 |
Let me add a note that the implementation of the options -L / -P in the Bourne Shell has been finished on January 20 2016 and that the Bourne Shell implementation defaults to -P and disallows cd "". This behavior has been chosen to avoid a change (compared to previous behavior) that seems to be suitable to affect security. This bug is related to 0001047 |
(0003412) geoffclare (manager) 2016-10-13 15:57 |
(Response to Note: 0002985) Similar problems occur with cd -P, and in my experience are more likely than problems that occur with cd -L. I frequently use sequences such as: cd somedir cd ../otherdir cd .. which work as expected with -L as the default if somedir or otherdir are symlinks, but go wrong if -P is the default. I doubt if I have ever used: ls .. cd .. because it is more natural to use: cd .. ls |
(0003413) Don Cragun (manager) 2016-10-13 16:08 |
This was discussed at length during the development of the POSIX.2-1992 standard and the arguments have not changed. 24 years of history with -L as the default make changing the behavior to implementation-defined or unspecified more of a security problem than either behavior as a defined requirement. We do not agree that -P is inherently safer than -L and do not believe that changing the specification at this time will improve security in any way. Therefore, this change is rejected. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |