Austin Group Defect Tracker

Aardvark Mark IV

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


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

- Relationships
related to 0001047Closed 1003.1(2013)/Issue7+TC1 Unspecified behaviour for cd "" causes a safety issue 

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

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.

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?
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
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.
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
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 ..
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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker