Re: [gentoo-user] User eix-sync permissions problem

[Kerin Millar <kerframil@fastmail.co.uk>]

On 10/02/2014 23:57, Walter Dnes wrote:
> On Mon, Feb 10, 2014 at 11:10:50PM +0000, Kerin Millar wrote
>
>> As mentioned in a few other posts, recent snapshots are portage:portage
>> throughout so it's a done deal for new installations.
>
>    How "recent"?  Looking back into ~/Maildir/spam/cur/ I see that the
> email file suffix changed from ".d531:2,S" to ".i660:2,S" on May 14th,
> 2013 (i.e. the current machine "i660" was installed and pulling mail as
> of that date).

I do not know but I would assume that the snapshots have been 
constructed in this fashion since (at least) the point where usersync 
became a default feature, which was in portage-2.1.13.

>
>>   Those who still have it owned by root can benefit from usersync
>>   simply by running:
>>
>> # chown -R portage:portage "$(portageq envvar PORTDIR)"
>>
>> There is no subsequent requirement not to invoke emerge --sync as root.
>
>    What's the point, if you still have to run as root (or su or sudo) for
> the emerge update process?
>

It's the principle of least privilege. Is there any specific reason for 
portage to fork and exec rsync as root? Is rsync sandboxed? Should rsync 
have unfettered read/write access to all mounted filesystems? Can it be 
guaranteed that rsync hasn't been compromised? Can it be guaranteed that 
PORTAGE_RSYNC_OPTS will contain safe options at all times?

The answer to all of these questions is "no". Basically, the combination 
of usersync and non-root ownership of PORTDIR hardens the process in a 
sensible way while conferring no disadvantage.

--Kerin