[prev in list] [next in list] [prev in thread] [next in thread] 

List:       illumos-developer
Subject:    Re: [developer] GNU Extended attribute API
From:       "Josef 'Jeff' Sipek" <jeffpc () josefsipek ! net>
Date:       2016-02-25 14:13:40
Message-ID: 20160225141340.GA1427 () meili ! valhalla ! 31bits ! net
[Download RAW message or body]

On Mon, Feb 22, 2016 at 15:54:42 +0000, Andy Stormont wrote:
> Hi,
> 
> I think it would be a good idea to add support for the GNU extended
> attribute API to illumos in an effort to make it easier to port code over.
> 
> For a long while GNU libattr provided a relatively sane API to extended
> attributes - now this API has been merged into glibc and the library only
> exists as a stub for backwards compatibility.  I propose we more or less
> mirror what they've done by adding support for the API to our libc and
> implement libattr as a filter library.
> 
> The work that Igor Pashev has done porting an older version of libattr to
> Solaris can be reused to make this happen quickly.  He has also given me
> permission to relicense this code under CDDL:
> http://cgit.osdyson.org/attr/commit/?id=74a46085bbffdfc3d69681bb951c45b85c03ddf7

This looks simple enough.  However it simply wraps the O_XATTR stuff we have
in illumos in a couple of functions.  Extended attributes on Linux are a bit
more than just <key,value>.  Specifically, there are a couple of namespaces
for attribute names.  From what I remember there are four namespaces: user,
system, trusted, and security.  The use visible xattr names are of the form:
"<namespace>.<key>" - for example: "user.blah".

Given that this lib interfaces is meant for compatibility with Linux, my
questions here are:

(1) Do we want to enforce this namespacing?  We obviously must not restrict
    O_XATTR behavior.  In other words, do we want to:

    (a) listxattr: skip over xattrs not following "<namespace>.<name>" format
    (b) getxattr/setxattr/removexattr: return EINVAL/other error if the
        requested name doesn't follow "<namespace>.<name>"

    I could easily see a program expecting this namespaced format, and
    trying to do strchr(x, '.') on a string coming back from listxattr.  On
    Linux that will always give a !NULL.  If we don't filter the xattrs,
    it's possible for the program to get a O_XATTR name, which will lead to
    strchr(x, '.') returning NULL and all sort of bad things happening after
    that.

(2) IIRC, Linux VFS limits the keys to 255 bytes and values to 64kB.
    Individual file systems can of course have lower limits.  I could see
    applications making assumptions about expected size and our effectively
    unlimited sizes could cause troubles.

> Before doing any work to this end I wanted to gauge what the response
> would be.  Do people support this idea?

I like it.

Jeff.

-- 
Don't drink and derive. Alcohol and algebra don't mix.


-------------------------------------------
illumos-developer
Archives: https://www.listbox.com/member/archive/182179/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182179/25758058-4e9228dc
Modify Your Subscription: https://www.listbox.com/member/?member_id=25758058&id_secret=25758058-c19b436a
Powered by Listbox: http://www.listbox.com
[prev in list] [next in list] [prev in thread] [next in thread]