[systemd-devel] [PATCH] tmpfiles, man: Add xattr support to tmpfiles

[Lennart Poettering]

On Wed, 19.06.13 17:02, Maciej Wereski (m.wereski at partner.samsung.com) wrote:

Heya,

> >I think adding this certainly makes sense, but I am not sure I like the
> >syntax. Maybe it would be simpler to add an extra char for this ("a" or
> >so?). That way creating a dir and applying an xattr would require two
> >lines instead of one, but the stuff isn't atomic anyway.
> >
> >Admittedly adding a new "a" isn't particularly nice either, but I have
> >no better idea than that...
> 
> I've looked into your way and found some problems. In parse_line(),
> after creating, item is added to hashmap. Key is path, which already
> exists in map. So adding "a" would require changing key (path +
> type?). 

Hmm, no actually, the best approach is to just update the existing entry
I think.

So, currently we go through the files line by line and then check if
there's already a line for this specific path, and if so, if it is
conflicting. Now, what I'd like to see is a slight extension to this for
the xattr case: if you have an "a" line, and there's already some other
line, and they match in everything, then simply add the xattr to the
existing line. We will apply all attributes only after parsing all
files, hence everything should be pretty clean.

Of course, you need to be careful when "merging" the two lines. i.e. you
cannot merge all kinds of lines, only some combinations make sense
(i.e. merging "r" and "a" certainly doesn't make sense. "f" and "a"
certainly does). Also, be careful that listing first the xattr line and
then the other one works equally well as doing it the other way round. I
guess "a" lines should "dissolve" into other lines, and only survive on
their own if there are no other lines matching the same file name.

I figure in the long run we might want to come up with an algebra for
merging more kinds of line type combinations, but for now I'd keep it
simple, and allow merging only these "a" lines with the very specific
other line types you need or where things are obvious. If figure merging
"a" into f, F, w, d, D, p, c, b, z probably makes sense, and that's it.

And then later on we could do a similar logic for applying acls, and
maybe "z" should be one of the "merging" types that is dissolved by
others too... But yeah, that shouldn't be of your concern (unless you
want to hack this up, too, would be much appreciated ;-)).

> I've also found something which looks like a typo in lines 782 - 787:
>              case RELABEL_PATH:
> 
>                     r = glob_item(i, item_set_perms);
>                     if (r < 0)
>                             return 0;
>                     break;
> 
> Shouldn't it be "return r"? If it's not, then should I add comment, that
> it's on purpose?

That looks like an error. Fixed locally now, will push soon! Thanks!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.