checkinstall hid my root partition
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
checkinstall (Debian) |
Fix Released
|
Unknown
|
|||
checkinstall (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
I use an alias to update my GNU Emacs source tree from CVS, configure it, build it, and run 'checkinstall' to make a package from the binaries.
I was trying to track down a bug recently introduced into Emacs, so I wasn't too concerned about having it installed, or even packaged, so I ran my alias and hit control C as soon as it got to the checkinstall part.
Immediately upon hitting control C my xfce4 panels disappeared. I still had a terminal window available. I typed 'ls' but 'ls' couldn't be found.
I rebooted, and found that I couldn't log in. /home/chris couldn't be found.
I rebooted into debian and found that my dapper "/" partition was owned by root:root and had permissions "drwx------" (700). There was also a directory /no-backup/ containing a single, empty file: /no-backup/
I believe that installwatch had done this somehow. I see this code in installwatch.c
strcpy (backup_path, getenv ("INSTALLWATCH_
strncat (backup_path, "/no-backup/", 11);
strcat (backup_path, path);
make_
so it looks like the getenv() call possibly returned an empty string. That would cause the 'no-backup' directory to be made in the root directory. I also see this code:
i=0;
blen = strlen (getenv ("INSTALLWATCH_
while ( path[i] != '\0' ) {
checkdir[i] = backup_path[blen+i] = path[i];
if (checkdir[i] == '/') { /* Each time a '/' is found, check if the */
if (!stat (checkdir, &inode)) {
}
}
i++;
}
That code would run chmod() on "/" if the getenv returned an empty string, but it shouldn't, as far as I can see, change the permissions on "/", since it would use the permissions that were already on "/".
In summary, checkinstall really messed up dapper for me, but I don't know why.
Changed in checkinstall: | |
status: | Unknown → Fix Released |
Am Donnerstag, den 08.12.2005, 22:31 -0600 schrieb Felipe Sanchez:
> Well, the first thing that would be useful to know is exactly what
> options did you use the last time you ran checkinstall. It would be really
> useful for trying to figure out what actually happened to your system.
> Please send it ;-)
Well, I did not use any command line parameters with checkinstall. When
I got asked for a package description I simply typed 'JRE', the package
name was 'fabian' and I changed the version number to '1.5', because
'dpkg' wants it to be a number.
That's what I *guess* to be the latest settings. As I stated before, the
errors occured when I wanted to get back from root to a normal user. So
there have been some minutes running 'dpkg -c' and 'dpkg -I' and similar
to test the package...
After some googling I found out that there are people who had the same
problem after using checkinstall.
German Debian Forum: beta.debianforu m.de/forum/ viewtopic. php?t=51830> ubuntuforums. org/showthread. php?mode= hybrid& t=54147>
<http://
Ubuntu Forum:
<http://
In the German forum the user tells that he tried to cancel checkinstall
via 'ctrl+c' because he forgot to set some settings.
Same for me! I also remember I have canceled one (or more) of the
several checkinstall runs beacuse I entered wrong settings accidentally
(e.g. non-digit version number, 'yes' to include temporary files from
home dir, etc.).
I guess that is where the bug hides!
Wehen you cancel checkinstall at the wrong point, some restrictions are
not set back?!
> The second thing is, the other week I wanted to delete a file from my
> system. I had some trouble doing it. So I played with some of the options
> of the rm program and suddenly my system became completely unstable! Upon
> examination and after a lot of work I found out that the thing had removed
> half of the files of my system!
Well, I understand what you are going to tell me, BUT:
'rm' is a program to delete files, 'checkinstall' is not a program to
set permissions. I would never send a bug report to the 'chmod'
maintainer because I accidentelly set my filesystem's permissions to 700
myself!
And, as I stated before, I did not use different options that touch
checkinstall, but played around with settings like package description,
version, etc...
> The moral of the story: I agree with you, it MUST be guaranteed that no
> program leaves your system in such a state. I.e. don't mess with your
> system!
>
> But if the program's job IS to actually mess with the system (rm,
> checkinstall, installwatch, etc) then all you can do is to educate the
> user about it's proper use and do your best to avoid putting too much bugs
> in ;-)
Let's try to find out what the bug is and remove it...;)
Nice Greetings,
Fabian