[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.