Bug 185830 - anaconda run under kadischi corrupts the host build system?
anaconda run under kadischi corrupts the host build system?
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kadischi (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chitlesh GOORAH
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-18 20:51 EST by Jane Dogalt
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-26 15:18:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda log from instance of bug (41.03 KB, text/plain)
2006-03-19 05:03 EST, Jane Dogalt
no flags Details

  None (edit)
Description Jane Dogalt 2006-03-18 20:51:05 EST
Description of problem:
While running kadischi, the network on my system (the host build system) was
reconfigured.  Specifically, it has a static IP address.  The kadischi kickstart
file I was using specified dhcp.  During the phase where the output of my
commandline kickstart install was paused on this output

---
Installing openoffice.org-graphicfilter-2.0.1.1-11.2.2...  Done [404/404]
Performing post install configuration...
---

the network got reconfigured.  I noticed because I was logged in via ssh.  I
then went to the console, did a /etc/init.d/network restart, and it switched
back to the static ip address and things were happy.

Version-Release number of selected component (if applicable):


How reproducible:
Haven't tried yet, but I suspect very reproducable.


Steps to Reproduce:
1. use command like the following 

kadischi -C --kickstart=/path/to/testks.cfg /mnt/fc5t3 /opt/kadisos/test.iso

2. have system configured with one ethernet, with a static ip address and able
to get a different ip via a dhcp server if it was so configured

3. use a kickstart file like the following
# kad: doing an install, not an upgrade
install

# kad: no install media setting
#cdrom

# kad: english/us default
lang en_US.UTF-8
langsupport --default=en_US fr_FR
keyboard us

# kad: as generic as possible
mouse --device=/dev/input/mice genericwheelusb

# kad: as generic as possible xconfig
# kad: for _now_, assume vesa video driver
# kad: for _now_, assume a respectable low end monitor
#monitor:: Generic CRT Display; Monitor 1024x768; MS_1024; 31.5-57.0; 50-70

xconfig --noprobe --driver="vesa" --resolution=1024x768 --depth=16
--startxonboot --hsync=31.5-57.0
--vsync=50-70 --defaultdesktop=GNOME

# kad: bug workaround, need to have an entry here for non-interactive
network --device=eth0 --bootproto=dhcp --hostname="alpha.livecd.example"

# kad: stateless install, post install and runtime scripts will deal with
#      dynamic runtime hardware autoconfiguration
#device eth0 xxx --opts=""
device eth0 tulip --opts=""

# kad: not so secret root password
#rootpw --iscrypted <insert crypted pw here>
rootpw secret

# kad: closed firewall should provide decent initial safety
#firewall --enabled --port=22:tcp
firewall --enabled --port=22:tcp

# default
authconfig --enableshadow --enablemd5

# kad: selinux not yet happy with kadischi
#selinux --enforcing
selinux --disabled

# kad: Kansas is the center of the world right?  GoogleEarth thinks so.
timezone --utc America/Chicago

# kad: bootloader handled by kadischi
bootloader --location=none

# kad: no partitioning for livecds
#clearpart --none

# kad: no firstboot
firstboot --disable

# kad: don't wait for user interaction
#halt/poweroff/reboot
reboot

# kad: non-interactive install
# text/cmdline(or graphical if not specified)
cmdline

%packages
@base
@office

# kad: experiment
#%post
%post --nochroot
cp -v /etc/hosts /etc/hosts.buildsystem

  
Actual results:


Expected results:


Additional info:

was using a fairly default fc5t3 install, and cvs version of kadischi.  I've
been following the fedora-livecd-devel list recently, and haven't noticed any
recent changes which might involve this behavior.

This seems like it is probably a bug with the way anaconda is run on the
kadischi build system.  Anaconda should not be doing anything that could effect
the build host system.  If kadischi could(can it?) be run as a user instead of
root, this sort of system corruption would not be possible.
Comment 1 Jasper O. Hartline 2006-03-19 00:39:19 EST
I was unable to reproduce this issue.
If you could try to, that would be good, and provide the 
/tmp/anaconda.log after occurance.

There was another report where Anaconda nuked a /etc/resolv.conf file.
Which, seems highly unlikely since /etc/resolv.conf is modified by hand or by
dhclient(8) on a host system.

They could be related, may not be.
Comment 2 Jane Dogalt 2006-03-19 05:03:40 EST
Created attachment 126323 [details]
anaconda log from instance of bug

/tmp/anaconda.log from a run that invoked this error.
Comment 3 Jane Dogalt 2006-03-19 05:07:04 EST
yes, it's 100% reproducable.  3 times in a row.  And after pouring over the
anaconda code for the last few hours, I think anaconda is just lightyears away
from being remotely safe to run on a host system that you care about not
corrupting.  I think I'm going to start investing time into generating my base
system with vmware or xen, rather than falling into this category 

"
# let people be stupid
## # don't let folks do anything stupid on !s390
## if (not flags.test and os.getpid() > 90 and flags.setupFilesystems and
##     not iutil.getArch() == "s390"):
##     sys.stderr.write(
##         "You're running me on a live system! that's incredibly stupid.\n")
##     sys.exit(1)

"

Also, here are some /var/log/messages from the host system.  Yes, this daemon is
running on the host system.  Somehow I doubt the 3 times this behaviour
happening at the same point in a kadischi(anaconda) run, was a coincidence.

Mar 18 15:38:25 rig avahi-daemon[2068]: Withdrawing address record for
192.168.1.203 on eth0.
Mar 18 15:38:25 rig avahi-daemon[2068]: Interface eth0.IPv4 no longer relevant
for mDNS.
Mar 18 15:38:26 rig avahi-daemon[2068]: New relevant interface eth0.IPv4 for mDNS.
Mar 18 15:38:26 rig avahi-daemon[2068]: Joining mDNS multicast group on
interface eth0.IPv4 with address 192.168.1.105.
Mar 18 15:38:26 rig avahi-daemon[2068]: IP_ADD_MEMBERSHIP failed: Address
already in use
Mar 18 15:38:26 rig avahi-daemon[2068]: Registering new address record for
192.168.1.105 on eth0.
Comment 4 Jane Dogalt 2006-03-19 13:40:37 EST
Ok, I was a bit tired/frustrated last night.  I should note that the anaconda
let people be stupid line doesn't directly apply to kadischi, as

flags.setupFilesystems is false for us

But the comment about running anaconda on a live system being incredibly stupid
is a case where the author had the forethought to emphasize a point that should
have been emphasized.

My question is:  what is the assumption with anaconda --rootpath.  Should any
aspect of the system, other than the contents of the rootpath directory be
effected by anaconda?  If that is the assumption, and I think it is, then this
bug is an example of something that slipped through the cracks.  And I suspect
there may still be others.  I'm curious, could some selinux policy hacker come
up with a way to restrict anacondas priveleges to only being able to modify
files under rootpath?  I.e. if it ever tries to touch any other files, or
hardware, it gets slapped down by the MCP (sorry, I watched tron recently).
Comment 5 Jasper O. Hartline 2006-03-19 18:10:18 EST
I'm trying to reproduce this, and simply can't.
I have several machines here also with static IP addresses.
Also using kickstart with any options other than the current host system.

I would suggest filing a bz entry under Anaconda and be sure to reference this
bug number there also, likewise that one here as they are related.
Comment 6 Jane Dogalt 2006-03-19 20:07:21 EST
note, that anaconda is also resetting the timezone, which I confirmed from
skunk's post on fedora-livecd.

Here is the terminal and anaconda.log output and specifically exactly where the
tails on a remote machine hung because the build machine's ip address changed. 
Note also the evidence of the timezone bug-

terminal output -

Installing xorg-x11-drv-siliconmotion-1.3.1.5-1.1...  Done [467/479]
Installing xorg-x11-drv-v4l-0.0.1.5-1.1...  Done [468/479]
Installing xorg-

/tmp/anaconda.log output -

06:50:11 DEBUG   : ignoring openjade>docbook-dtds in whiteout
06:50:28 DEBUG   : ignoring nautilus>nautilus-cd-burner in whiteout
06:50:41 INFO    : moving (1) to step install
06:50:41 INFO    : moving (1) to step enablefilesystems
06:50:41 INFO    : moving (1) to step migratefilesystems
06:50:41 INFO    : moving (1) to step setuptime
04:50:41 INFO    : moving (1) to step preinstallconfig
04:50:41 INFO    : moving (1) to step installpackages
04:50:41 INFO    : Preparing to install packages

Comment 7 Jane Dogalt 2006-03-19 20:17:18 EST
a couple other quick things I noticed.  Being paranoid I did an ls -altr on the
host system after the kadischi build.

/etc/resolv.conf changed, obviously due to picking up a dynamic nameserver when
it went to dhcp (the /etc/init.d/network restart failed to recover my orig
resolv.conf).

/etc/mtab changed, but I'll assume that was do to some chroot
mounting/unmounting of proc.

But *** importantly, I noticed these peculiar entries in my /etc

lrwxrwxrwx  1 root root      27 Mar 12 10:46 protocol -> ../mnt/runtime/etc/protocol
lrwxrwxrwx  1 root root      22 Mar 12 10:46 joe -> ../mnt/runtime/etc/joe
-

And of course /etc/localtime was also modified as par the timezone bug.

Comment 8 Jasper O. Hartline 2006-03-30 13:24:44 EST
Maybe this needs to be reassigned to anaconda-maintenance.

Unfortunately I cannot find any traces of this behavior on three different
systems of varying hardware types, and FC4/FC5.
Comment 9 Jeremy Katz 2006-04-26 15:18:27 EDT
These should be fixed in anaconda CVS.

Note You need to log in before you can comment on or make changes to this bug.