duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Solaris: Restore/GPG issues


From: Martin Pool
Subject: Re: [Duplicity-talk] Solaris: Restore/GPG issues
Date: Tue, 4 Oct 2011 10:58:43 +1100

On 4 October 2011 08:07, Scott Severtson <address@hidden> wrote:
> All,
> We'd prefer to run Duplicity as a non-root user, but it seems Duplicity
> requires elevated privileges on Solaris to restore file
> ownership/permissions.
>
> When we run a restore operation as a non-root user (and Solaris' privilege
> debugging enabled), we get messages like:

I think that on every modern Unix (or certainly most) only root can
change the ownership of a file, and only root can change the
permissions of a file owned by someone else.  So if you want to
restore files owned by multiple users, you need to either run as root
or perhaps do something with capabilities (which might be OS-specific)
to allow it to chmod/chown/chgrps.

>
> ---
> --- Start running command FETCH at 14:46:00.000 ---
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: Mon Oct  3 10:44:08 2011
> gpg[241]: missing privilege "ZONE" (euid = 70003, syscall = 23) needed at
> setuid+0x64
> gpg[387]: missing privilege "ZONE" (euid = 70003, syscall = 23) needed at
> setuid+0x64
> duplicity[29161]: missing privilege "file_chown_self" (euid = 70003, syscall
> = 16) needed at zfs_setattr+0x2ec
> Error '[Errno 1] Not owner: '/vault/restore/foo'' processing .
> ---
>
> So, to allow GPG/Duplicity to set file permissions, we tried running a
> restore as a root-equivalent user. Now, before we even start restoring
> files, GPG fails with the following error:
>
> ---
> gpg: fatal: failed to reset uid: Error 0
> secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768
> ---

If by 'root-equivalent user' you mean one with uid 0: why?  Is there
any advantage over just using root?

m



reply via email to

[Prev in Thread] Current Thread [Next in Thread]