bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] xattr support for ext2fs


From: Kalle Olavi Niemitalo
Subject: Re: [PATCH 1/2] xattr support for ext2fs
Date: Thu, 07 Jul 2016 11:35:56 +0300
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.51 (gnu/linux)

LastAvengers <lastavengers@outlook.com> writes:

> +/* Prefixes are represented as numbers when stored in ext2 filesystems. */
> +struct _xattr_prefix
> +xattr_prefixes[] =
> +{
> +  {
> +  1, "user.", sizeof "user." - 1},
> +  {
> +  7, "gnu.", sizeof "gnu." - 1},
> +  {
> +  0, NULL, 0}
> +};

ext4 on Linux 4.5 already uses 7 for EXT4_XATTR_INDEX_SYSTEM
but lists it in neither ext4_xattr_handler_map nor
ext4_xattr_handlers.  I think that means the index does not map
to any prefix visible to user mode, not even to
#define XATTR_SYSTEM_PREFIX "system.".  Instead, ext4 uses
{ EXT4_XATTR_INDEX_SYSTEM, "data" } internally for inline data.
http://lxr.free-electrons.com/ident?v=4.5;i=ext4_xattr_handler_map

So if you use 7 then I think these xattrs will not be accessible
from current Linux.  And I think ext4 developers would not be
happy to change ext4 to let them through if they intended
EXT4_XATTR_INDEX_SYSTEM for ext4 internal use.

"[linux 2.6 patch] ext2 support for hurd extensions via xattr interface"
https://lists.gnu.org/archive/html/bug-hurd/2004-02/msg00108.html
defined EXT2_XATTR_INDEX_HURD as 7 but AFAICT it did not store
that index on disk so it did not have this kind of problem.

What are the alternatives then:

(a) Store as { EXT4_XATTR_INDEX_SYSTEM = 7, "translator" }
    like you intended.
    Con: The xattr would be inaccessible from current Linux.

(b) Store as { EXT4_ATTR_INDEX_USER = 1, "gnu.translator" }.
    On Linux, applications would see "user.gnu.translator".
    Pro: Anyone able to write to the file would also be able
         to modify the xattr, like on the Hurd.
    Pro: The attribute could be accessed via CIFS too.
    Con: Linux might not allow such xattrs on special files
         like fifos or symlinks.  That's not a problem for the
         translator xattr (because being a special file already
         implies what the translator is) but might be for the
         author xattr.
    Con: I don't know whether it's right for the operating system
         to reserve names in the "user." namespace.  There is
         precedent in cachefiles_xattr_cache = "user.CacheFiles.cache"
         though, and the "gnu." part seems clear enough.
    http://lxr.free-electrons.com/source/fs/xattr.c?v=4.5#L32

(c) Ask the ext4 developers to reserve a new index for "gnu.",
    and store as { EXT_ATTR_INDEX_GNU, "translator" }.
    Con: The xattr would be inaccessible from current Linux.
    Pro: Later versions of Linux could display it as "gnu.translator"
         and let users modify the attribute just like with "user.".
    Con: The attribute could not be accessed via CIFS.
         That is unlikely to matter in practice though.

(d) Store as { 0, "gnu.translator" }.
    Con: I think it would be inaccessible from Linux.

Alternative (b) seems easiest and sane enough.

Is there any practical use for the author ID anyway?
I think most files in my computer were authored by people
who don't have UIDs in my /etc/passwd.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]