0001013: cd and pwd should not default to -L - Austin Group Defect Tracker

Notes
(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.

Issue History
Date Modified	Username	Field	Change
2015-12-16 16:48	joerg	New Issue
2015-12-16 16:48	joerg	Status	New => Under Review
2015-12-16 16:48	joerg	Assigned To	=> ajosey
2015-12-16 16:48	joerg	Name	=> Jörg Schilling
2015-12-16 16:48	joerg	Section	=> Utilities
2015-12-16 16:48	joerg	Page Number	=> 2530 + 3093
2015-12-16 16:48	joerg	Line Number	=> 81644-81646 + 103207-103208
2015-12-16 23:00	shware_systems	Note Added: 0002979
2015-12-16 23:01	shware_systems	Note Edited: 0002979
2015-12-17 10:48	joerg	Note Added: 0002980
2015-12-17 14:03	user229	Note Added: 0002984
2015-12-17 16:06	a brouwer	Note Added: 0002985
2015-12-17 16:19	shware_systems	Note Added: 0002987
2015-12-21 15:41	joerg	Note Edited: 0002980
2016-04-29 09:18	joerg	Note Added: 0003187
2016-10-13 15:57	geoffclare	Note Added: 0003412
2016-10-13 16:08	Don Cragun	Interp Status	=> ---
2016-10-13 16:08	Don Cragun	Note Added: 0003413
2016-10-13 16:08	Don Cragun	Status	Under Review => Closed
2016-10-13 16:08	Don Cragun	Resolution	Open => Rejected
2017-06-01 15:20	eblake	Relationship added	related to 0001047

Aardvark Mark IV