Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

CWD-relative ROOT support in portage: misfeature?

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


gmt at malth

Aug 17, 2012, 8:00 PM

Post #1 of 3 (233 views)
Permalink
CWD-relative ROOT support in portage: misfeature?

It has come to my attention that gentoo supports "relative" ROOT, which
is to say that, by design, portage will act as though (in bash terms):

ROOT

equals

"${PWD}/${ROOT}"

when (again in bash terms):

[[ $ROOT != /* ]]

at the moment execution crosses the boundary between a non-portage
program and a portage program. For example, I ran the following from a
bash-prompt with PWD=/tmp in a portage-2.2 ~amd64 environment:

greg [at] fedora64vm /tmp $ mkdir foo
greg [at] fedora64vm /tmp $ ROOT=foo portageq envvar ROOT
/tmp/foo/

Question: do we really want this behavior?

I have reason to believe that almost nobody uses this feature (namely,
gcc-config and binutils-config are both broken under it for ages and
nobody filed a bug or fixed it: see bugzilla #431104).

Does /anybody/ use this feature? If not, I'd suggest that the portage
team might ask itself whether the benefits of continuing to maintain it
are greater than the hassle and potential for error it facilitates.

Just my 2c,

-gmt


axs at gentoo

Aug 18, 2012, 5:50 PM

Post #2 of 3 (222 views)
Permalink
Re: CWD-relative ROOT support in portage: misfeature? [In reply to]

On 2012-08-17, at 11:00 PM, "Gregory M. Turner" <gmt [at] malth> wrote:

> It has come to my attention that gentoo supports "relative" ROOT, which is to say that, by design, portage will act as though (in bash terms):
>
> ROOT
>
> equals
>
> "${PWD}/${ROOT}"
>
> when (again in bash terms):
>
> [[ $ROOT != /* ]]
>
> at the moment execution crosses the boundary between a non-portage program and a portage program. For example, I ran the following from a bash-prompt with PWD=/tmp in a portage-2.2 ~amd64 environment:
>
> greg [at] fedora64vm /tmp $ mkdir foo
> greg [at] fedora64vm /tmp $ ROOT=foo portageq envvar ROOT
> /tmp/foo/
>
> Question: do we really want this behavior?
>
> I have reason to believe that almost nobody uses this feature (namely, gcc-config and binutils-config are both broken under it for ages and nobody filed a bug or fixed it: see bugzilla #431104).
>
> Does /anybody/ use this feature? If not, I'd suggest that the portage team might ask itself whether the benefits of continuing to maintain it are greater than the hassle and potential for error it facilitates.
>
> Just my 2c,
>
> -gmt


Sorry for the HTML response... am on the road.

I don't use the feature but I would fully expect said behavior. ie, going with the example above I would expect that I'd need the / in front for the path to not be relative.






>


gmt at malth

Aug 19, 2012, 8:00 AM

Post #3 of 3 (227 views)
Permalink
Re: CWD-relative ROOT support in portage: misfeature? [In reply to]

On 8/18/2012 5:50 PM, Ian Stakenvicius wrote:
>
> On 2012-08-17, at 11:00 PM, "Gregory M. Turner" <gmt [at] malth> wrote:
>
>> greg [at] fedora64vm /tmp $ mkdir foo
>> greg [at] fedora64vm /tmp $ ROOT=foo portageq envvar ROOT
>> /tmp/foo/
>>
>> Does /anybody/ use this feature?
>
> Sorry for the HTML response... am on the road.
>
> I don't use the feature but I would fully expect said behavior. ie, going with the example above I would expect that I'd need the / in front for the path to not be relative.

A user and maintainer of this (vapier) has emerged. I pooh-poohed the
relative-ROOT idea when I discovered it a few days ago, but I've
flip-flopped. I was concerned it would be exploitable by Bad
People(tm), but I think it's no more exploitable than absolute-only
ROOT, so long as its implemented correctly.

So far, nobody's turned up to advocate against the status quo (except
me, but I'm fine with it now), so I think the matter can be considered
resolved.

-gmt

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.