duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

I've run cx-freeze as well and I like it (gsutil on Freebsd).  From the
standpoint of isolation it would give us the ability to supply all versions
of all needed modules as well as the Python version itself (for those that
refuse to upgrade).  The cost is that the package becomes huge, but it's
just tradeoff, our support time vs a bit of their storage space.

What we might consider doing is both a frozen and a non-frozen version.
The users still on Python 2.4 (gack!) could upgrade to the latest and
greatest by using the frozen version, while the more advanced could upgrade
normally.  I know it works on all Linux distros and Freebsd.

As to file capabilities, that will depend on what kernel version they are
running and whether it's baked into the filesystem.  I suppose the code
could check for availability, use if possible and operate as normal if not.

On Fri, Jun 5, 2015 at 12:27 PM, James Wilson <jmw@xxxxxxxxxxxx> wrote:

> Hey, I wanted to resume this discussion. Since April a couple of things
> have changed: 1) I helped the maintainer of libcap-ng to fix its build
> issues as of 0.7.4-3 that is available in sid and stretch, and 2) I found
> another way to limit root capabilities using file capabilities that has a
> smaller footprint (it doesn't create a new system user).
>
> The catch for #2 is that file capabilities need a real binary executable,
> because the kernel ignores file capabilities set on interpreted programs. I
> found a utility called cx_Freeze that uses a minimal binary loader to start
> up the python environment and run a bundled script. Then we can set
> inherited file capabilities on /usr/bin/duplicity in the post-install
> script. The inherited capabilities cannot be harnessed unless the executing
> user also has the same capabilities in their inherited set, which the
> system administrator can take care of by granting inherited capabilities on
> the backup user. The easiest way to do this is using pam_cap.so. One
> possible issue is that cx_Freeze is available as an ubuntu package
> (cx-freeze) but it is not in Debian.
>
> I've been running a custom version of duplicity with this setup for
> several weeks. It's a cleaner solution since it doesn't require a specific
> duplicity user to exist. The tradeoff is that system-wide backups require
> more setup since the system administrator will need to set up the inherited
> user capabilities. It's worth adding some documentation on how to do all of
> this.
>
> Are either of these directions something you'd like to consider now?
> --
> https://code.launchpad.net/~jmwilson/duplicity/capabilities/+merge/257488
> You are subscribed to branch lp:duplicity.
>

-- 
https://code.launchpad.net/~jmwilson/duplicity/capabilities/+merge/257488
Your team duplicity-team is requested to review the proposed merge of lp:~jmwilson/duplicity/capabilities into lp:duplicity.