Discussion:
[ast-developers] Wrong error returned by cd -@ if filesystem does not support extended attributes (O_XATTR)
Joshuah Hurst
11 years ago
Permalink
ksh93 does not report the correct kind of error when cd -@ is used for
a filesystem which doesn't support extended attributes (O_XATTR) like
/devices on Solaris :

ksh -c 'cd -@ /devices ; :'
/home/josh/bin/ksh: cd: /dev/file/xattr@/devices//@//: [No such file
or directory]

It should return the EINVAL from openat(3, ".",
O_RDONLY|O_NONBLOCK|O_XATTR) from the truss log below:

stat(".", 0xFFFFFD7FFFDFF8C8) = 0
sigaction(SIGCLD, 0xFFFFFD7FFFDFF920, 0xFFFFFD7FFFDFF998) = 0
lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000,
0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
openat(10, "/devices", O_RDONLY|O_NONBLOCK) = 3
fstat(3, 0xFFFFFD7FFFDFE400) = 0
fcntl(3, F_SETFD, 0x00000001) = 0
openat(3, ".", O_RDONLY|O_NONBLOCK|O_XATTR) Err#22 EINVAL
close(3) = 0
openat(10, "/dev/file/xattr@/devices//@//", O_RDONLY|O_NONBLOCK) Err#2 ENOENT
open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/SUNW_OST_OSLIB.mo",
O_RDONLY) Err#2 ENOENT
/home/josh/bin/ksh: cd: /dev/file/xattr@/devices//@//: [No such file
or directory]
write(2, " / h o m e / j o s h / 0 0".., 86) = 86
close(10) = 0
fstat(1, 0xFFFFFD7FFFDFF828) = 0
fstat(2, 0xFFFFFD7FFFDFF828) = 0
_exit(0)

Also why does it do a openat(10, "/dev/file/xattr@/devices//@//",
O_RDONLY|O_NONBLOCK)?
That's totally wrong.

Josh

---------- Forwarded message ----------
From: Joshuah Hurst <joshhurst at gmail.com>
Date: Wed, Nov 6, 2013 at 1:16 PM
Subject: [bug] Problem with cd -@ if filesystem does not support
extended attributes (O_XATTR)
To: bug-bash at gnu.org, Chester Ramey <chet.ramey at case.edu>


Chet, on Solaris the /devices filesystem does not support extended
attributes (O_XATTR), yet cd -@ returns 0 (success):

./bash -c 'cd -@ /devices 2>/dev/null; echo $?'
0
~/bin/ksh -c 'cd -@ /devices 2>/dev/null; echo $?'
1

truss shows that bash gets errno==EINVAL but then uses
chdir("/devices") instead of returning the error:
stat64("/devices", 0x08047520) = 0
open64("/devices", O_RDONLY|O_NONBLOCK) = 3
openat64(3, ".", O_RDONLY|O_XATTR) Err#22 EINVAL
close(3) = 0
chdir("/devices") = 0
brk(0x0819C000) = 0

Josh
Glenn Fowler
11 years ago
Permalink
thanks for the detailed report
the ast::pathdev() function has a few compile-time code paths on
defined(O_XATTR)
the one with defined(O_XATTR)!=0 but fails on a particular fs is the least
exercised
I think this patch will resolve it but I'm not sure about consequences
w.r.t. other callers
unfortunately for the near-term I only have build access to my home suse
machine with defined(O_XATTR)==0
so we'll have to rely on the community to test
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20131107/19ae34d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libast-pathcanon-2013-11-07.patch
Type: text/x-patch
Size: 348 bytes
Desc: not available
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20131107/19ae34d6/attachment.bin>
Joshuah Hurst
11 years ago
Permalink
Post by Glenn Fowler
thanks for the detailed report
the ast::pathdev() function has a few compile-time code paths on
defined(O_XATTR)
the one with defined(O_XATTR)!=0 but fails on a particular fs is the least
exercised
I think this patch will resolve it but I'm not sure about consequences
w.r.t. other callers
unfortunately for the near-term I only have build access to my home suse
machine with defined(O_XATTR)==0
so we'll have to rely on the community to test
The patch does not work. I am still getting No such file or directory
instead of Invalid value and the extra openat(10,
"/dev/file/xattr@/devices//@//") call still happens:

openat(10, "/devices", O_RDONLY|O_NONBLOCK) = 3
fstat(3, 0xFFFFFD7FFFDFE3E0) = 0
fcntl(3, F_SETFD, 0x00000001) = 0
openat(3, ".", O_RDONLY|O_NONBLOCK|O_XATTR) Err#22 EINVAL
close(3) = 0
openat(10, "/dev/file/xattr@/devices//@//", O_RDONLY|O_NONBLOCK) Err#2 ENOENT
open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/SUNW_OST_OSLIB.mo",
O_RDONLY) Err#2 ENOENT
./arch/sol11.i386-64/bin/ksh: cd: /dev/file/xattr@/devices//@//: [No
such file or directory]
write(2, " . / a r c h / s o l 1 1".., 93) = 93

Josh
Roland Mainz
11 years ago
Permalink
...
Erm... Glenn's patch is OK so far... but there is a 2nd issue... if
|pathdev()| fails the error is ignored and the real path is passed to
|openat()| again...

----

Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
Roland Mainz
11 years ago
Permalink
...
Attached (as "astksh20131010_xattr_solaris_fswithoutxattr001.diff.txt")
is a patch which fixes the issues...

... Glenn: Is the patch OK for you ?

----

Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
-------------- next part --------------
diff -r -u build_i386_64bit_debug/src/lib/libast/path/pathcanon.c build_gsffix/src/lib/libast/path/pathcanon.c
--- src/lib/libast/path/pathcanon.c 2013-09-27 11:17:46.000000000 +0200
+++ src/lib/libast/path/pathcanon.c 2013-11-08 11:52:31.315746992 +0100
@@ -535,9 +535,12 @@
r = 0;
else if ((n = openat(dev->fd, ".", O_INTERCEPT|O_RDONLY|O_XATTR|O_NONBLOCK)) < 0)
{
+ int saved_errno = errno;
r = 0;
close(dev->fd);
dev->fd = -1;
+ errno = saved_errno;
+ return 0;
}
else
{
diff -r -u build_i386_64bit_debug/src/lib/libast/path/pathopen.c build_gsffix/src/lib/libast/path/pathopen.c
--- src/lib/libast/path/pathopen.c 2013-09-27 11:17:46.000000000 +0200
+++ src/lib/libast/path/pathopen.c 2013-11-08 11:40:07.824442260 +0100
@@ -168,7 +168,9 @@

b = canon ? canon : (char*)path;
if (!pathdev(dfd, path, canon, size, flags, &dev))
- b = (char*)path;
+ {
+ return -1;
+ }
else if (dev.path.offset)
{
oerrno = errno;
Glenn Fowler
11 years ago
Permalink
looks good
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20131112/fc3eeca9/attachment.html>
Loading...