Bug#863751: adduser should be able to create a btrfs-subvol instead of a normal directory for $HOME

[Jakobus Schürz]

Package: adduser
Version: 3.115
Severity: wishlist

Dear Maintainer,

btrfs is a gread filesystem. But adduser can not create a
btrfs-subvolume for users home. Please add the functionality for
creating a btrfs-subvolume instead of a directory.

Thank you

Jakob


-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (800, 'unstable'), (1, 'experimental')
Architecture: amd64
(x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages adduser depends on:
ii debconf [debconf-2.0] 1.5.61
ii passwd 1:4.4-4.1

adduser recommends no packages.

Versions of packages adduser suggests:
ii liblocale-gettext-perl 1.07-3+b1
ii perl 5.24.1-2

-- debconf information:
adduser/homedir-permission: true
adduser/title:

[Osamu Aoki]

control tags -1 patch

thanks

The current useradd since 2019 has --btrfs-subvolume-home option.


$ useradd -h
Usage: useradd [options] LOGIN
useradd -D
useradd -D [options]

Options:
...
--btrfs-subvolume-home use BTRFS subvolume for home directory
...
(Yes, its manpage may need to be updated)


All we need is to add it to the adduser wrapper.

Here is my first try to add it. Please use this as a starting place.

I don't know if this option should be used for --system or not. Now it
is enabled. Please consider this point before adding this feature for
bulleseye+1=Bookworm

Regards,

Osamu

[Marc Haber]

Control: retitle -1 use useradd's --btrfs-subvolume-home option
thanks

On Sun, Feb 21, 2021 at 08:52:39PM +0900, Osamu Aoki wrote:
> The current useradd since 2019 has --btrfs-subvolume-home option.

How does this option behave if the parent of the new home directory is
not on btrfs? adduser could add this option to all useradd calls but
this would only be possible if useradd will _silently_ ignore the option
if the parent directory is not btrfs and of course create a normal
directory in that case. If the operation is not silent, package
maintainers are going to redirect adduser's output to /dev/null which is
not desired from adduser's pov.

Greetings
Marc

[Osamu Aoki]

Hi,

Interesting POV. (opt-in vs. automatic)

I was thinking opt-in only.

I mean to add an opt-in --btrfs-subvolume-home option to adduser so the user can use
this feature if he requests. I didn't think beyond. (I didn't test it on non-btrfs
system so I don't know the answer to your question. Whoever specifies it in command
line, he should know it.)

As I come to think of this, since it is trivial to check FS of /home in adduser in
advance by calling a basic shell command as:

```
$ stat -f -c %T /home
btrfs
```
, adding this feature as an automatic option for pertinent system is an interesting
thought for adduser too.

Osamu

[Marc Haber]

Hi,

On Tue, Mar 08, 2022 at 07:16:57PM +0900, Osamu Aoki wrote:
> I was thinking opt-in only.
>
> I mean to add an opt-in --btrfs-subvolume-home option to adduser so
> the user can use this feature if he requests. I didn't think beyond.
> (I didn't test it on non-btrfs system so I don't know the answer to
> your question. Whoever specifies it in command line, he should know
> it.)

I had a sane default in mind. As times have changed and maintainer /
developer resources are scarce, adduser primarily sees itself as a
policy wrapper to help package maintainers to create their package
accounts in their maintainer scripts without violating policy. Offering
account creation capabilities to the local admin has been pushed into
the background in the last decades.

I'd say then if the local admin wants to use a feature that adduser
doesnt offer, they are free to use other tools such as useradd directly
to get what they want.

> As I come to think of this, since it is trivial to check FS of /home
> in adduser in advance by calling a basic shell command as:
>
> ``` $ stat -f -c %T /home btrfs ``` , adding this feature as an
> automatic option for pertinent system is an interesting thought for
> adduser too.

I am reluctant to add filesystem specific code to adduser, as writing
automated tests is probably hard.

I would think more about adding this if having account-specific btrfs
subvolumes per _system_ account would be a valid feature to have AND if
useradd is smart enough to not error out or spew warnings if one tries
to create a btrfs subvolume on non-btrfs volumes. At th moment, I am not
convinced that this is worth spending developer / maintainer time on.

Would it help to have an "useradd-extra-options" command line option and
configuration file setting that causes their respective contents to
be added to useradd's command line verbatim? Which other commands would
need a respective foo-extra-options option?

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

[Osamu Aoki]

Hi,

> -----Original Message-----
> From: Marc Haber <mh+debian...@zugschlus.de>
> To: Osamu Aoki <os...@debian.org>
> Cc: 863...@bugs.debian.org, 863751-s...@bugs.debian.org, Nicholas D Steeves
> <st...@debian.org>
> Subject: Re: Bug#863751: Add --btrfs-subvolume-home option to adduser

> Date: Tue, 8 Mar 2022 14:21:09 +0100
>
> Hi,
>
> On Tue, Mar 08, 2022 at 07:16:57PM +0900, Osamu Aoki wrote:
> > I was thinking opt-in only.
> >
> > I mean to add an opt-in --btrfs-subvolume-home option to adduser so
> > the user can use this feature if he requests. I didn't think beyond.
> > (I didn't test it on non-btrfs system so I don't know the answer to
> > your question. Whoever specifies it in command line, he should know
> > it.)
>
> I had a sane default in mind. As times have changed and maintainer /
> developer resources are scarce, adduser primarily sees itself as a
> policy wrapper to help package maintainers to create their package
> accounts in their maintainer scripts without violating policy. Offering
> account creation capabilities to the local admin has been pushed into
> the background in the last decades.

I now understand your POV and where it came from.

> I'd say then if the local admin wants to use a feature that adduser
> doesnt offer, they are free to use other tools such as useradd directly
> to get what they want.

Yes. That's basically what I do here trivially. (I still use adduser. After whole
standard d-i installation, I rename the primary user's home directory from root
account on console and create subvolume in place and copy data into it.)

> > As I come to think of this, since it is trivial to check FS of /home
> > in adduser in advance by calling a basic shell command as:
> >
> > ``` $ stat -f -c %T /home btrfs ``` , adding this feature as an
> > automatic option for pertinent system is an interesting thought for
> > adduser too.
>
> I am reluctant to add filesystem specific code to adduser, as writing
> automated tests is probably hard.

I think it causes some dependency increase and resource drain for you. (I don't think
it is so exotic to do this.)

TBH, I am not pushing this patch after hearing back from you. I now think the best
action is to label this as "wontfix" on condition until followings become about to be
reached.

* Linux kernel supports btrfs as its primary filesystem over ext4.
* useradd manpage (not -h output) explicitly includes this option.
* Debian installer considers to support btrfs as root filesystem as out-of-box
feature and this becomes a required feature of installation process.

When these things are on horizon, this feature may be desirable one to have for user
to make sharpshoots of their data easily.

> I would think more about adding this if having account-specific btrfs
> subvolumes per _system_ account would be a valid feature to have AND if
> useradd is smart enough to not error out or spew warnings if one tries
> to create a btrfs subvolume on non-btrfs volumes. At th moment, I am not
> convinced that this is worth spending developer / maintainer time on.

As I see many so-called _system_ accounts in /etc/passwd, their home directory are
everywhere under /var, /bin, /usr/bin, ... It they become separate btrfs subvolume,
making snapshot script will be nightmare to address all. So it's bad idea to do so
unless some rare maintainer script specifically request so (sbuild, apt-cacher-ng may
be good candidate if their maintainer wishes but most _system_ account using
/nonexistent, /bin . /var/... as home directory shall not use this to maintain easy
snapshot recoverable system). Anyway, practically that kind of question happens only
when debian-installer start supporting installation of system root on btrfs subvolume
as default and some packages start taking advantage.

Your concern for your time is valid one to reject this patch.

> Would it help to have an "useradd-extra-options" command line option and
> configuration file setting that causes their respective contents to
> be added to useradd's command line verbatim? Which other commands would
> need a respective foo-extra-options option?
>

As I said above, I don't see such benefit under current situation for most of
_system_ accounts. This is useful mostly for user accounts.

Currently, Debian can be installed and booted from btrfs subvolume using d-i but that
requires a lot of manual tweakings. Compared to them, user's home directory as btrfs
subvolume is a minor non-essential tweak.

Regards,

Osamu

[Osamu Aoki]

Hi,

I should have checked my typos more.

Important corrections are:

WRONG: make sharpshoots of their data easily.
CORRECT: make snapshots of their data easily.

WRONG: It they become separate btrfs subvolume,
CORRECT: If they become separate btrfs subvolume,

(There are many other errors such as 3rd person singular "s" for verbs ...)

Osamu

[Marc Haber]

Control: tags -1 wontfix
Control: severity -1 wishlist

On Wed, Mar 09, 2022 at 10:05:26AM +0900, Osamu Aoki wrote:
> > -----Original Message-----
> > From: Marc Haber <mh+debian...@zugschlus.de>
> > To: Osamu Aoki <os...@debian.org>
> > Cc: 863...@bugs.debian.org, 863751-s...@bugs.debian.org, Nicholas D Steeves
> > <st...@debian.org>
> > Subject: Re: Bug#863751: Add --btrfs-subvolume-home option to adduser
> > Date: Tue, 8 Mar 2022 14:21:09 +0100
> >
> > Hi,
> >
> > On Tue, Mar 08, 2022 at 07:16:57PM +0900, Osamu Aoki wrote:
> > > I was thinking opt-in only.
> > >
> > > I mean to add an opt-in --btrfs-subvolume-home option to adduser so
> > > the user can use this feature if he requests. I didn't think beyond.
> > > (I didn't test it on non-btrfs system so I don't know the answer to
> > > your question. Whoever specifies it in command line, he should know
> > > it.)
> >
> > I had a sane default in mind. As times have changed and maintainer /
> > developer resources are scarce, adduser primarily sees itself as a
> > policy wrapper to help package maintainers to create their package
> > accounts in their maintainer scripts without violating policy. Offering
> > account creation capabilities to the local admin has been pushed into
> > the background in the last decades.
>
> I now understand your POV and where it came from.

Thanks for your understanding. I appreciate that.

> > I'd say then if the local admin wants to use a feature that adduser
> > doesnt offer, they are free to use other tools such as useradd directly
> > to get what they want.
>
> Yes. That's basically what I do here trivially. (I still use adduser. After whole
> standard d-i installation, I rename the primary user's home directory from root
> account on console and create subvolume in place and copy data into it.)

Thats how I would do it as well, yes.

> TBH, I am not pushing this patch after hearing back from you. I now think the best
> action is to label this as "wontfix" on condition until followings become about to be
> reached.

Will do.

> * Debian installer considers to support btrfs as root filesystem as out-of-box
> feature and this becomes a required feature of installation process.

I think that would be a strong point, yes.

> > I would think more about adding this if having account-specific btrfs
> > subvolumes per _system_ account would be a valid feature to have AND if
> > useradd is smart enough to not error out or spew warnings if one tries
> > to create a btrfs subvolume on non-btrfs volumes. At th moment, I am not
> > convinced that this is worth spending developer / maintainer time on.
>
> As I see many so-called _system_ accounts in /etc/passwd, their home directory are
> everywhere under /var, /bin, /usr/bin, ... It they become separate btrfs subvolume,
> making snapshot script will be nightmare to address all. So it's bad idea to do so
> unless some rare maintainer script specifically request so (sbuild, apt-cacher-ng may
> be good candidate if their maintainer wishes but most _system_ account using
> /nonexistent, /bin . /var/... as home directory shall not use this to maintain easy
> snapshot recoverable system).

Noted. Thanks for your evaluation and explanation.