On Sun, Dec 27, 2020 at 11:32 PM Dan Čermák
<dan.cer...@cgc-instruments.com> wrote:

> I have not really looked into the source code, so forgive me if that is
> obvious, but why is the snebu executable setuid?

This is for
1) Privilege separation -- application owns the files in the target
repository (/var/lib/snebu); you will typically be running the backup
front-end (snebu-client) as root so it can read everything, but the
snebu binary that gets called doesn't need root access.
2) Permissions model -- You can set up service user accounts for each
host (client) that is submitting backups (so they can see only their
own backup, or they can submit backups but not expire old backups
[expiration permissions would be assigned to a separate maintenance
user for further protection], etc.).  This protects you in the case of
a client compromise so an attacker can't delete all your backups.

> The spec file is mostly good, I'd suggest a few changes though:
> - use macros instead of hardcoded paths, e.g. %_bindir instead of
>   /usr/bin/
> - don't disable the debug package generation, Fedora packages must
>   include debuginfo versions
> - replace make %{?_smp_mflags} with:
>   %set_build_flags
>   %make_build
> - mark LICENSE.txt as %license and not as %doc
> - there is no need to install the documentation under
>   /usr/share/doc/snebu manually, you can just add the following into
>   %files and rpmbuild will copy the files into the right place:
>   %doc readme.md
>   %doc snebu.adoc

OK, will do.

> - I'd recommend to replace the %pre check for the snebu user with a
>   systemd-sysusers config:
>   https://fedoraproject.org/wiki/Changes/SystemdSysusers

I tried this initially but couldn't get it to work inside a VM booted
from a Fedora Live image.  I followed the instructions here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
and created the appropriate file snebu.sysusers, but the pre install
with this line in it:

%sysusers_create_compat %{SOURCE1}

I'll test again with a full install in the VM instead of the live
install and see if that makes a difference.

Also, if I want the spec file to be compatible with older RHEL
releases (that predate the %sysusers_create_compat macro), should that
just be a separate spec for each version?  or should I wrap the above
in a conditional (test for the macro and fallback to manual account
creation)?

> And one general issue not directly related to rpmbuild itself: does your
> Makefile honor the CFLAGS & LDFLAGS environment variables? Because if it
> does not, then all the compiler hardening flags that %set_build_flags
> inject will be just ignored.

I'll add this in.  Also the make file needed the $(CC) variable instead of gcc.

Meanwhile, a couple additional questions.  Right now I have a template
of the spec file in the project's Git repo.  Should the spec file be
in its own repo (or possibly an orphaned branch of this repo)?  That
way all packaging-specific items can be versioned separately from the
app itself.

Secondly, I'll put the above Makefile modifications in shortly, but it
may be a bit before the next posted release of Snebu.  So for the
purpose of the RPM, should I put them in as patches (that are owned by
the rpm) until the next Snebu release comes out?

Thanks.

--Derek Pressnall
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to