[gentoo-user] /var/cache/edb

[gentoo-user] /var/cache/edb

[Ian Zimmerman]

What is this directory, and especially its dep/ subdirectory?  Do I
really need it?  What programs read and write it?

(equery b prints nothing.)

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] /var/cache/edb

[Mike Gilbert]

On Tue, Dec 13, 2016 at 10:59 PM, Ian Zimmerman <itz@primate.net> wrote:
> What is this directory, and especially its dep/ subdirectory?  Do I
> really need it?  What programs read and write it?

That's a cache directory that portage uses. It is generally safe to
remove it; portage will regenerate the information the next time you
run it.

The dep subdirectory contains cached dependency information for
ebuilds. It only gets populated if you locally modify ebuilds on your
system; otherwise, the metadata directory from the repository
(/usr/portage/metadata) is used instead.

For ebuild developers that use a git development repo, there is no
metadata in the repository, so the /var/cache/edb/dep directory sees
much more use.

[gentoo-user] Re: /var/cache/edb

[Ian Zimmerman]

On 2016-12-13 23:19, Mike Gilbert wrote:

> The dep subdirectory contains cached dependency information for
> ebuilds. It only gets populated if you locally modify ebuilds on your
> system; otherwise, the metadata directory from the repository
> (/usr/portage/metadata) is used instead.

I see stuff in that subdirectory related to overlays I have enabled via
layman, and ebuilds provided by those overlays, even when I'm _not_
using these ebuilds but the ebuilds for the same packages provided by
gentoo itself.  Or so I hope - for all such overlays I've masked */* and
only unmasked the 1 or 2 particular packages I need, which aren't in
gentoo.

The true reason the directory bothers me is its permissions, and those
of the files inside.  They seem to be created as portage:portage, 0660.
Why is root:root 0640 not good enough for them?  Does that mean some
part of portage runs setuid/setgid to the portage user/group?

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Re: /var/cache/edb

[Rich Freeman]

On Wed, Dec 14, 2016 at 5:25 PM, Ian Zimmerman <itz@primate.net> wrote:
>
> The true reason the directory bothers me is its permissions, and those
> of the files inside.  They seem to be created as portage:portage, 0660.
> Why is root:root 0640 not good enough for them?  Does that mean some
> part of portage runs setuid/setgid to the portage user/group?
>

Yes, this is a security feature (which you can turn off in FEATURES).
It reduces the impact of rogue Makefiles and such.

-- 
Rich

Re: [gentoo-user] Re: /var/cache/edb

[Mike Gilbert]

On Wed, Dec 14, 2016 at 5:25 PM, Ian Zimmerman <itz@primate.net> wrote:
> On 2016-12-13 23:19, Mike Gilbert wrote:
>
>> The dep subdirectory contains cached dependency information for
>> ebuilds. It only gets populated if you locally modify ebuilds on your
>> system; otherwise, the metadata directory from the repository
>> (/usr/portage/metadata) is used instead.
>
> I see stuff in that subdirectory related to overlays I have enabled via
> layman, and ebuilds provided by those overlays, even when I'm _not_
> using these ebuilds but the ebuilds for the same packages provided by
> gentoo itself.  Or so I hope - for all such overlays I've masked */* and
> only unmasked the 1 or 2 particular packages I need, which aren't in
> gentoo.

Those overlays probably do not include a pre-generated metadata cache directory.

> The true reason the directory bothers me is its permissions, and those
> of the files inside.  They seem to be created as portage:portage, 0660.
> Why is root:root 0640 not good enough for them?  Does that mean some
> part of portage runs setuid/setgid to the portage user/group?

Those permissions allow any member of the portage group to regenerate
cache entries, which is a handy feature for developers.

I don't really see how it would represent any security risk.