Re: tmpfs support of xattrs?

[Casey Schaufler <casey@schaufler-ca.com>]

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.