linux-ext4 - Re: How to package e2scrub

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 31 May 2019 10:10:19 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org,
        Jan Kara <jack@...e.com>
Subject: Re: How to package e2scrub

On Fri, May 31, 2019 at 12:07:13PM +0200, Jan Kara wrote:
> On Thu 30-05-19 09:51:55, Theodore Ts'o wrote:
> > On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote:
> > > Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
> > > support only systemd init anyway these days (and in fact our distro people
> > > want to deprecate cron in favor of systemd). I guess I'll split off the
> > > scrub bits into a separate sub-package (likely e2fsprogs will suggest
> > > installation of this sub-package) and the service will be disabled by
> > > default.
> > 
> > I'm not super-fond of extra sub-packages for their own sake, and the
> > extra e2scrub bits are small enough (about 32k?) that I don't believe
> > it justifies an extra sub-package; but that's a distribution-level
> > packaging decision, so it's certainly fine if we're not completely aligned.
> 
> Yes, size is not a big concern but the scrub bits require util-linux, lvm,
> and mailer to work correctly and I don't want to add these dependencies to
> stock e2fsprogs package because some minimal installations do not want e.g.
> lvm at all. Granted these are just scripts so I could get away with not
> requiring e.g. lvm at all but it seems user-unfriendly to leave it up to
> user to determine that his systemd-service fails due to missing packages.

So you're using an extra package to force the installation of the
necessary prerequisite packages, instead of the current approach where
we don't require them, but we just skip running the scrub if lvm and
util-linux are not present.  I think both approaches makes sense.

It's also a good point that we need to handle the case of a missing
sendmail intelligently.  It looks like we currently skip sending mail
at all in the cron case, and in the case systemd case, we'll spew a
warning (which won't get mailed since there's no sendmail, but it does
mean some extra lines in the logfile).  All of this being said, it's
not _completely_ useless to scrub without an mailer; we still mark the
file system as needing to be checked on the next boot.  But it's
another argument that we shouldn't enable the service by default.

For that reason, I'm not sure I'd want to force the installation of a
mailer, since someone might want to run e2scrub by hand, and
e2scrub_all every week w/o isn't a completely insane thing.  But we
certainly should handle that case gracefully.

     	     	      	      		- Ted