[lkml]   [2008]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: tmpfs support of xattrs?
    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_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:
    >>> Patches:
    >>> 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.

     \ /
      Last update: 2008-10-27 22:57    [W:0.041 / U:5.968 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site