[gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Vitaly Ivanov]

Hello all

"To protect or not to protect..."

emerge tool overwrite files in CONFIG_PROTECT if ROOT != '/'

for example:
   CONFIG_PROTECT="/etc /opt/gentoos/hostname/root/etc"
   ROOT="/opt/gentoos/hostname/root/"
   emerge something
overwrite files in /opt/gentoos/hostname/root/etc

I found the comments of Nicholas Jones in bug 
http://bugs.gentoo.org/show_bug.cgi?id=52415
 >> Portage makes the assumption that if you're installing
 >> into a new root, then you're building a system and
 >> shouldn't bother with config protection. It's not
 >> documented either way, so it's undefined behavior.

But if I really want to overwrite those files
I can do it by
CONFIG_PROTECT="-*"
ROOT="/opt/gentoos/hostname/root/"
emerge something

I can't chroot to /opt/gentoos/hostname/root and emerge there,
because it is cross compilation and I can't protect those files
in any way now.

May be protect *all* files in CONFIG_PROTECT
even if ROOT != '/'
This behavior can be easy override by CONFIG_PROTECT="-*"
in command line if needed.

Thanks.


-- 
Vitaly Ivanov
email: va@mail.ru
icq uin: 15918498
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vitaly Ivanov wrote:
> I found the comments of Nicholas Jones in bug
> http://bugs.gentoo.org/show_bug.cgi?id=52415
>>> Portage makes the assumption that if you're installing
>>> into a new root, then you're building a system and
>>> shouldn't bother with config protection. It's not
>>> documented either way, so it's undefined behavior.

I disagree with that logic, because people may be maintaining systems in
a ROOT with modified config files. Updating those systems trashes the
files. Thank you for pointing out this behavior now, because it walks
all over plans I have for a diskless cluster.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCNgBOXVaO67S1rtsRAqwXAKD1gXa1Du1kUQl2SpmxGHKTIl+u3ACg++D1
yEnWNpiVD2Fhg97Tic7ZcFo=
=9nYL
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Brian Jackson]

On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Vitaly Ivanov wrote:
> > I found the comments of Nicholas Jones in bug
> > http://bugs.gentoo.org/show_bug.cgi?id=52415
> >>> Portage makes the assumption that if you're installing
> >>> into a new root, then you're building a system and
> >>> shouldn't bother with config protection. It's not
> >>> documented either way, so it's undefined behavior.
> 
> I disagree with that logic, because people may be maintaining systems in
> a ROOT with modified config files. Updating those systems trashes the
> files. Thank you for pointing out this behavior now, because it walks
> all over plans I have for a diskless cluster.

I mentioned this to the portage guys the other day. Either they didn't
care, or they didn't hear me. Either way, probably need to file a bug
about it (or stir up that other one).

--Iggy

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Brian Jackson]

On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Vitaly Ivanov wrote:
> > I found the comments of Nicholas Jones in bug
> > http://bugs.gentoo.org/show_bug.cgi?id=52415
> >>> Portage makes the assumption that if you're installing
> >>> into a new root, then you're building a system and
> >>> shouldn't bother with config protection. It's not
> >>> documented either way, so it's undefined behavior.
> 
> I disagree with that logic, because people may be maintaining systems in
> a ROOT with modified config files. Updating those systems trashes the
> files. Thank you for pointing out this behavior now, because it walks
> all over plans I have for a diskless cluster.

I mentioned this to the portage guys the other day. Either they didn't
care, or they didn't hear me. Either way, probably need to file a bug
about it (or stir up that other one).

--Iggy

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]

maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
> On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
> > Vitaly Ivanov wrote:
> > > I found the comments of Nicholas Jones in bug
> > > http://bugs.gentoo.org/show_bug.cgi?id=52415
> > >>> Portage makes the assumption that if you're installing
> > >>> into a new root, then you're building a system and
> > >>> shouldn't bother with config protection. It's not
> > >>> documented either way, so it's undefined behavior.
> > 
> > I disagree with that logic, because people may be maintaining systems in
> > a ROOT with modified config files. Updating those systems trashes the
> > files. Thank you for pointing out this behavior now, because it walks
> > all over plans I have for a diskless cluster.
> 
> I mentioned this to the portage guys the other day. Either they didn't
> care, or they didn't hear me. Either way, probably need to file a bug
> about it (or stir up that other one).

Alright! The bug is getting attention, and it even hasn't been a year!

I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415 that
addresses the issue.  You can directly do

wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch -p0

which will in turn screw your portage.py, but hopefully for the best.

As I see that there are more people who are interested in the bug, I am
expecting at least some to trust me enough as to try out the patch and
in turn make some noise (yeah, noise is what we need) when it makes them
happy.

The other problem that bothers me (that is: reading configuration
files from $ROOT) seems to be worked on. At least, there are
comments like:

	# XXX: This should depend on ROOT?
	if os.path.exists("/"+CUSTOM_PROFILE_PATH):
		self.user_profile_dir = os.path.normpath("/"+"///"+CUSTOM_PROFILE_PATH)
		self.profiles.append(self.user_profile_dir[:])

...

	# XXX: Should depend on root?
		self.mygcfg=getconfig("/"+MAKE_CONF_FILE,allow_sourcing=True)
		if self.mygcfg == None:
			self.mygcfg = {}


Which I guess means that it will sooner or later make it to the next
level in some form.

chutz out

-- 
*)   Georgi Georgiev   *) Live fast, die young, and leave a flat       *)
(*    chutz@gg3.net    (* patch of fur on the highway! -- The          (*
*)  +81(90)6266-1163   *) Squirrels' Motto (The "Hell's Angels of      *)
(* ------------------- (* Nature")                                     (*

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Brian Jackson]

On 12:56:00 am 2005-03-15 Georgi Georgiev <chutz@gg3.net> wrote:
> maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
> >  On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
> > >  Vitaly Ivanov wrote:
> > > >  I found the comments of Nicholas Jones in bug
> > > >  http://bugs.gentoo.org/show_bug.cgi?id=52415
> > > >>>  Portage makes the assumption that if you're installing
> > > >>>  into a new root, then you're building a system and
> > > >>>  shouldn't bother with config protection. It's not
> > > >>>  documented either way, so it's undefined behavior.
> > >
> > >  I disagree with that logic, because people may be maintaining
> > >  systems in a ROOT with modified config files. Updating those
> > >  systems trashes the files. Thank you for pointing out this
> > >  behavior now, because it walks all over plans I have for a
> >  diskless cluster.
> >  I mentioned this to the portage guys the other day. Either they
> >  didn't care, or they didn't hear me. Either way, probably need to
> >  file a bug about it (or stir up that other one).
>
> Alright! The bug is getting attention, and it even hasn't been a year!
>
> I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415 that
> addresses the issue.  You can directly do
>
> wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch -p0
>
> which will in turn screw your portage.py, but hopefully for the best.
>
> As I see that there are more people who are interested in the bug, I
> am expecting at least some to trust me enough as to try out the patch
> and in turn make some noise (yeah, noise is what we need) when it
> makes them happy.
>
> The other problem that bothers me (that is: reading configuration
> files from $ROOT) seems to be worked on. At least, there are
> comments like:

I have a bug filed for that too, but it's probably going to be a while
before it's fixed. From what I've been told, it's not trivial to fix it
because some of the config stuff isn't very well abstracted.

http://bugs.gentoo.org/show_bug.cgi?id=73350

--Iggy

>
>     # XXX: This should depend on ROOT?
>     if os.path.exists("/"+CUSTOM_PROFILE_PATH):
>         self.user_profile_dir = os.path.normpath("/"+"///"+CUSTOM_PROF
> ILE_PATH)
>         self.profiles.append(self.user_profile_dir[:])
>
> ...
>
>     # XXX: Should depend on root?
>         self.mygcfg=getconfig("/"+MAKE_CONF_FILE,allow_sourcing=True)
>         if self.mygcfg == None:
>             self.mygcfg = {}
>
>
> Which I guess means that it will sooner or later make it to the next
> level in some form.
>
> chutz out

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Georgi Georgiev]

maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
> On 12:56:00 am 2005-03-15 Georgi Georgiev <chutz@gg3.net> wrote:
> > maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
> > >  On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
> > > >  Vitaly Ivanov wrote:
> > > > >  I found the comments of Nicholas Jones in bug
> > > > >  http://bugs.gentoo.org/show_bug.cgi?id=52415
> > > > >>>  Portage makes the assumption that if you're installing
> > > > >>>  into a new root, then you're building a system and
> > > > >>>  shouldn't bother with config protection. It's not
> > > > >>>  documented either way, so it's undefined behavior.
> > > >
> > > >  I disagree with that logic, because people may be maintaining
> > > >  systems in a ROOT with modified config files. Updating those
> > > >  systems trashes the files. Thank you for pointing out this
> > > >  behavior now, because it walks all over plans I have for a
> > >  diskless cluster.
> > >  I mentioned this to the portage guys the other day. Either they
> > >  didn't care, or they didn't hear me. Either way, probably need to
> > >  file a bug about it (or stir up that other one).
> >
> > Alright! The bug is getting attention, and it even hasn't been a year!
> >
> > I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415 that
> > addresses the issue.  You can directly do
> >
> > wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch -p0
> >
> > which will in turn screw your portage.py, but hopefully for the best.
> >
> > As I see that there are more people who are interested in the bug, I
> > am expecting at least some to trust me enough as to try out the patch
> > and in turn make some noise (yeah, noise is what we need) when it
> > makes them happy.
> >
> > The other problem that bothers me (that is: reading configuration
> > files from $ROOT) seems to be worked on. At least, there are
> > comments like:
> 
> I have a bug filed for that too, but it's probably going to be a while
> before it's fixed. From what I've been told, it's not trivial to fix it
> because some of the config stuff isn't very well abstracted.

It isn't? Are we talking about the same thing? After all, the locations
are just variables, that only need to be prefixed with something. Could
we get some input from whoever told you this?

> http://bugs.gentoo.org/show_bug.cgi?id=73350

-- 
 )   Georgi Georgiev    ) Sure he's sharp as a razor ... he's a two-    )
(     chutz@gg3.net    (  dimensional pinhead!                         (
 )  +81(90)6266-1163    )                                               )
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Brian Jackson]

On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@gg3.net> wrote:
> maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
> >  On 12:56:00 am 2005-03-15 Georgi Georgiev <chutz@gg3.net> wrote:
> > >  maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
> > > >   On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
> > > > >   Vitaly Ivanov wrote:
> > > > > >   I found the comments of Nicholas Jones in bug
> > > > > >   http://bugs.gentoo.org/show_bug.cgi?id=52415
> > > > > >>>   Portage makes the assumption that if you're installing
> > > > > >>>   into a new root, then you're building a system and
> > > > > >>>   shouldn't bother with config protection. It's not
> > > > > >>>   documented either way, so it's undefined behavior.
> > > > >
> > > > >   I disagree with that logic, because people may be
> > > > >   maintaining systems in a ROOT with modified config files.
> > > > >   Updating those systems trashes the files. Thank you for
> > > > >   pointing out this behavior now, because it walks all over
> > > >   plans I have for a diskless cluster.
> > > >   I mentioned this to the portage guys the other day. Either
> > > >   they didn't care, or they didn't hear me. Either way,
> > > >   probably need to file a bug about it (or stir up that other
> > > one).
> > >  Alright! The bug is getting attention, and it even hasn't been a
> > > year!
> > >  I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415
> > >  that addresses the issue.  You can directly do
> > >
> > >  wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch
> > > -p0
> > >  which will in turn screw your portage.py, but hopefully for the
> > > best.
> > >  As I see that there are more people who are interested in the
> > >  bug, I am expecting at least some to trust me enough as to try
> > >  out the patch and in turn make some noise (yeah, noise is what
> > >  we need) when it makes them happy.
> > >
> > >  The other problem that bothers me (that is: reading configuration
> > >  files from $ROOT) seems to be worked on. At least, there are
> > >  comments like:
> >
> >  I have a bug filed for that too, but it's probably going to be a
> >  while before it's fixed. From what I've been told, it's not
> >  trivial to fix it because some of the config stuff isn't very well
> abstracted.
>
> It isn't? Are we talking about the same thing? After all, the
> locations are just variables, that only need to be prefixed with
> something. Could we get some input from whoever told you this?

make.conf is easy. The profile isn't as easy. /etc/portage isn't easy at
all. That's the basics. You'd have to ask the portage guys for more in
depth info.

--Iggy

>
> >  http://bugs.gentoo.org/show_bug.cgi?id=73350

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Georgi Georgiev]

maillog: 15/03/2005-12:01:47(-0600): Brian Jackson types
> On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@gg3.net> wrote:
> > maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
> > >  I have a bug filed for that too, but it's probably going to be a
> > >  while before it's fixed. From what I've been told, it's not
> > >  trivial to fix it because some of the config stuff isn't very
> > >  well abstracted.
> >
> > It isn't? Are we talking about the same thing? After all, the
> > locations are just variables, that only need to be prefixed with
> > something. Could we get some input from whoever told you this?
> 
> make.conf is easy. The profile isn't as easy. /etc/portage isn't easy
> at all. That's the basics. You'd have to ask the portage guys for more
> in depth info.

I was hoping to get a response from them here. Portage guys, you there?

-- 
/    Georgi Georgiev   /  From 0 to "what seems to be the problem      /
\     chutz@gg3.net    \  officer" in 8.3 seconds. -- Ad for the new   \
/   +81(90)6266-1163   /  VW Corrado                                   /
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Brian Harring]

On Wed, Mar 16, 2005 at 08:05:43AM +0900, Georgi Georgiev wrote:
> maillog: 15/03/2005-12:01:47(-0600): Brian Jackson types
> > On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@gg3.net> wrote:
> > > maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
> > > >  I have a bug filed for that too, but it's probably going to be a
> > > >  while before it's fixed. From what I've been told, it's not
> > > >  trivial to fix it because some of the config stuff isn't very
> > > >  well abstracted.
> > >
> > > It isn't? Are we talking about the same thing? After all, the
> > > locations are just variables, that only need to be prefixed with
> > > something. Could we get some input from whoever told you this?
> > 
> > make.conf is easy. The profile isn't as easy. /etc/portage isn't easy
> > at all. That's the basics. You'd have to ask the portage guys for more
> > in depth info.
> 
> I was hoping to get a response from them here. Portage guys, you there?
http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/config.py?root=gentoo-src
^^^^ config class, cleaned up a bit from what stable has.

At the moment, my focus on the bugger is the following-
A) integration of env whitelist tracking, preferably in a an attached 
   instance (the need for this is partially bound to covering 
   filter-env's ass).
B) either reorganize the beast so env stuff is accessible via an 
   attribute, or create a container class that the config gets 
   assigned into
C) bind all tree instances to the config.  Why?  Kill off portage.db 
   global usage entirely, and try and encapsulate data into one 
   common, passable instance
D) shift virtual loading, setcpv, setinst, load_infodir, etc, all out 
   of config and to a proper class.

So... why tack that stuff in now, when the class itself needs a major 
enema? :)

Basically it comes down to a focus (at this point) in trying to 
improve the existing code/abstractions in use, rather then tacking 
more features/codepaths in.

Anyone interested can take a crack at the request above, it's just not 
high on my peronsal (likely our) list of priorities, since the 
existing code is spaghetti like.

Note that integration of env whitelisting *is* adding a new feature 
in.  It's kind of required to keep things sane for the env handling 
though (mainly, a few very crazy var settings are *very* hard to 
properly filter).  That and it can't be done without refactoring the 
config class anyways (which is intended)...
~harring
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Georgi Georgiev]

maillog: 15/03/2005-21:17:26(-0600): Brian Harring types
> On Wed, Mar 16, 2005 at 08:05:43AM +0900, Georgi Georgiev wrote:
> > maillog: 15/03/2005-12:01:47(-0600): Brian Jackson types
> > > On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@gg3.net> wrote:
> > > > maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
> > > > >  I have a bug filed for that too, but it's probably going to be a
> > > > >  while before it's fixed. From what I've been told, it's not
> > > > >  trivial to fix it because some of the config stuff isn't very
> > > > >  well abstracted.
> > > >
> > > > It isn't? Are we talking about the same thing? After all, the
> > > > locations are just variables, that only need to be prefixed with
> > > > something. Could we get some input from whoever told you this?
> > > 
> > > make.conf is easy. The profile isn't as easy. /etc/portage isn't easy
> > > at all. That's the basics. You'd have to ask the portage guys for more
> > > in depth info.
> > 
> > I was hoping to get a response from them here. Portage guys, you there?
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/config.py?root=gentoo-src
> ^^^^ config class, cleaned up a bit from what stable has.
> 
> At the moment, my focus on the bugger is the following-
> A) integration of env whitelist tracking, preferably in a an attached 
>    instance (the need for this is partially bound to covering 
>    filter-env's ass).
> B) either reorganize the beast so env stuff is accessible via an 
>    attribute, or create a container class that the config gets 
>    assigned into
> C) bind all tree instances to the config.  Why?  Kill off portage.db 
>    global usage entirely, and try and encapsulate data into one 
>    common, passable instance
> D) shift virtual loading, setcpv, setinst, load_infodir, etc, all out 
>    of config and to a proper class.
> 
> So... why tack that stuff in now, when the class itself needs a major 
> enema? :)
> 
> Basically it comes down to a focus (at this point) in trying to 
> improve the existing code/abstractions in use, rather then tacking 
> more features/codepaths in.
> 
> Anyone interested can take a crack at the request above, it's just not 
> high on my peronsal (likely our) list of priorities, since the 
> existing code is spaghetti like.
> 
> Note that integration of env whitelisting *is* adding a new feature 
> in.  It's kind of required to keep things sane for the env handling 
> though (mainly, a few very crazy var settings are *very* hard to 
> properly filter).  That and it can't be done without refactoring the 
> config class anyways (which is intended)...

Well, I never intended to rush things... bug #52415 has been open for
almost an year after all, and at least the config protection seems to be
more of a bug than a problem with the implementation (as I had posted in
a comment on the bug, $ROOT/etc/somefile is being checked against a list
that is not prefixed with a $ROOT).

The issue with the alternate configuration location is only a matter of
convenience, since it can be worked around with a couple of symlinks.
As your hands are full with other stuff, I'd only hope you keep the
request in mind. Maybe even post a note when you guys unknot the
spaghetti?

-- 
(    Georgi Georgiev   (  I went to a Grateful Dead Concert and they   (
 )    chutz@gg3.net     ) played for SEVEN hours. Great song. -- Fred   )
(   +81(90)6266-1163   (  Reuss                                        (
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Brian Harring]

On Wed, Mar 16, 2005 at 12:35:55PM +0900, Georgi Georgiev wrote:
> Well, I never intended to rush things... 
Rush isn't necessarily bad.  Portage bugs have a way of acruing years 
without action...

> Maybe even post a note when you guys unknot the
> spaghetti?
cvs head is becoming better... help/patches would be wonderful 
however. :):
~harring
--
gentoo-dev@gentoo.org mailing list