[Top][All Lists]

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

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

From: Scott Severtson
Subject: Re: [Duplicity-talk] Solaris: Restore/GPG issues
Date: Tue, 04 Oct 2011 09:38:46 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15


Thanks for the response. We found a combination of Solaris privileges that allowed the duplicity user to restore files with permissions, but without granting full root-level access:

/usr/sbin/usermod -K defaultpriv=basic,file_dac_read,file_dac_search,file_dac_write,file_chown_self,file_chown,file_owner ${DUPLICITY_USER}

Granted, the user has enough permissions to do plenty of damage to the filesystem, but is still limited to a subset of root's permissions (can't open lower ports, mount/unmount drives, mess with devices or priorities, etc).

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?
The user is not "root" nor uid=0, but had been granted the Solaris "zone" privilege. This effectively gives the user "root" permissions to the local zone, but is still a separate account.

We generally create "service" accounts for most activities, and grant the minimum elevated privileges required to accomplish their goal. In this case, we were experimenting with the "zone" privilege to see if it would allow restores to set file permissions. However, instead of helping, GPG started to fail as described above. We did not find a workaround for this, and will report this failure to the GPG bugtracker.


reply via email to

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