Re: tmpfs support of xattrs?

From: Casey Schaufler
Date: Mon Oct 27 2008 - 17:54:35 EST


Rob MacKinnon wrote:
Stephen Smalley wrote:
On Mon, 2008-10-27 at 13:14 -0700, Rob MacKinnon wrote:
Andreas Gruenbacher wrote:
On Sunday, 26 October 2008 13:26:35 Hugh Dickins wrote:
On Sat, 25 Oct 2008, Rob MacKinnon wrote:
The background: So during the initial configuration of a box I enabled
the xattr flags for ext3 and options of xattr in coreutils, and at the
time didn't realize that I'd hit a snag that would finally annoy me
enough after a month of getting a non-fatal error messages from cp "cp:
listing attributes of `/dev/null`: Invalid argument" to spend half a day
researching the cause and a potential solution.

Setup: udev mounts a tmpfs to /dev then fills it with device nodes.
Problem: the resulting tmpfs has no xattr support.
Therefore: Tmpfs without xattrs, and coreutils and everywhere else with
xattr support, cp freaks.

Is there sometime in the forseable future when the tmpfs module will
support for xattrs in the stable branch, or should I "holler at the
maintainers of coreutils to fix their broken code in cp". Even better
(and I like this option the most) a little of both?
I've not seen "cp: listing attributes of `/dev/null': Invalid argument"
messages (or.. do I have a dim recollection of them once upon a time?).
I would certainly get irritated by them if I did, and want to fix them.
I tried "cp /dev/null temp" on a few distros just now but not seen it.
As Hugh pointed out already, tmpfs does support xattrs since quite a while, so enabling that should fix the symptoms. Independent of that, cp must of course work correctly on filesystems that don't have xattrs. Those filesystems are not supposed to return EINVAL, though.

Could you please run cp under strace to show us what's happening at the syscall level (and perhaps under ltrace in addition to see the library level as well)?

If the error happens at the syscall level (*listxattr), then which kernel is it exactly, and where can I find its sources?

Thanks Andreas, Hugh & HPA

First off, thanks for looking into this. After googling around, hitting
forums and such and not getting any answers, this list seemed the best
place to come to ask.

Now onward to business...I can say that I too was under the general
understanding that xattr for tmpfs was added at 2.6.10...and was still
currently supported. Unfortunately I already have the config flags set
(as seen below, for a full config set attached) so there is a continued
confusion in my mind why this is still plaguing me.

I've had several friends compare what was going on, and of them they
were all running rhel and cent (most with no udev support so the
comparison didn't help at all).

I'll start out with distro info and the like...
`uname -a`="Linux shin-yuko 2.6.26-gentoo-r2 #1 SMP PREEMPT Wed Oct 22
16:31:40 PDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel
GNU/Linux"

coreutils-version="coreutils-6.12-r2"

My current config does have the following set:
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_SHMEM=y

Output from `strace /bin/cp /dev/null /root/temp`= #see attachment
Output from `ltrace -CS /bin/cp /dev/null /root/temp`= #see attachment

Output from `attr -l /dev/null`=Segfault (hmmm...lemme look at a strace
and ltrace of that too)

`strace attr -l /dev/null`= #see attachment
`ltrace -CS /bin/attr -l /dev/null`= #see attachment

Kernel source can be attained from:
http://distfiles.gentoo.org/distfiles/linux-2.6.26.tar.bz2

Patches:
http://sources.gentoo.org/viewcvs.py/linux-patches/genpatches-2.6/trunk/2.6.26/

I know this is silly but, setfattr and getfattr obviously don't work
either...just thought it was worth mentioning.
Looks like a bug in Smack's implementation of the inode_listsecurity
hook to me. Did you mean to enable Smack in your kernel config?


I had intensionally flipped CONFIG_SECURITY_SMACK to "y".

Thank you!

I'm used to
running hardened with GRSec and RBAC (ot: but found the gentoo
versioning was so far behind / and me being lazy and not wanting to
manually do the patching / I dropped using hardened sources) so when I
saw the option for what sounded like a good compromise I jumped at it.
Looks like I did a good thing too having uncovered a problem. :)

-- Rob

Yes indeed, and thank you. Stephen has already suggested a fix, I just
need to do some code, build, and test once I get to Smack time.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/