[systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Wed Apr 1 06:48:23 PDT 2015
On 04/01/2015 01:04 PM, Lennart Poettering wrote:
> On Wed, 01.04.15 12:40, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:
>
>>> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
>>> index 494fd1a..9280fd7 100644
>>> --- a/src/tmpfiles/tmpfiles.c
>>> +++ b/src/tmpfiles/tmpfiles.c
>>> @@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
>>> break;
>>> + case CREATE_SUBVOLUME:
>>> +
>>> + /* Don't create subvolumes in chrooted environments. */
>>> + if (running_in_chroot())
>>> + break;
>>> + /* FALLTHROUGH */
>>> +
>>> case CREATE_DIRECTORY:
>>> case TRUNCATE_DIRECTORY:
>>> - case CREATE_SUBVOLUME:
>>> RUN_WITH_UMASK(0000)
>>> mkdir_parents_label(i->path, 0755);
>>
>> This breakage is not limited to chroot, subvolumes should not be created et
>> all.
> Why not?
Because you break factory,stateless,reproducible,verifiable, mock and
variety of servers setups with enterprise storage of any kind that uses
btrfs ( and whatever else 'v' switch might support in the future ).
( Prime example that covers a lot of usecase where this breaks on btrfs
/var/lib/machines )
Let's leave it up to vendor and downstream distributions to make an
enlighten choice of turning the 'v' feature on after careful
consideration and creating relevant documentation instead of breaking
for them and have every distributions patching this "feature" out for
example because they suddenly found themselves in a pile of bug reports
because users could not delete those directories in the traditional
manner they had expected ( rm ) but had to magically discover they will
have to use the relevant subvolume removal command for the file system
in question on those directories that it had been enabled on .
Bottom line upstream default should always be 'd' as in create a
directory if it does not exist yet, never v as in create a subvolume if
the path does not exist yet and the file system supports it.
JBG
More information about the systemd-devel
mailing list