checkinstall can leave / as -rwx------ if interrupted

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:
<http://beta.debianforum.de/forum/viewtopic.php?t=51830>
Ubuntu Forum:
<http://ubuntuforums.org/showthread.php?mode=hybrid&t=54147>

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

Hi,

I had the same problem with checkinstall. After a running checkinstall
was interrupted for a network failure, I was unable to login.

Checking a root on the console showed permissions of / set to 700.

To me it seems that checkinstall does not like to be interupted.

FYI, it was was chan_misdn, as the debian packages are a bit outdated
(IMHO misdn evolves too fast currently for the debian packaging process)

Bye,

Joerg

package checkinstall
merge 342578 342633
thanks
--

Felipe Sateler

package checkinstall
tags 342578 unreproducible
tags 342633 unreproducible
thanks
I am unable to reproduce this bug. Has anyone found a way to reproduce this
bug reliably? If not, I'd like to have more information on how it was
produced, most precisely, at which point checkinstall is interrupted. Looking
at the code doesn't suggest any obvious place where this could be happening.
--

Felipe Sateler

# maintainer forgot to cc control@
package checkinstall
tags 342578 unreproducible
tags 342633 unreproducible
thanks

package checkinstall
tags 342578 +upstream
tags 342633 +upstream

thanks
--

Felipe Sateler

Package: checkinstall
Version: 1.5.3-3
Followup-For: Bug #342578

The problem is line 211 in the checkinstall script (version 1.5.3-3):
206 function restore_backup {
207 ls ${TMP_DIR}/backup/* &> /dev/null
208 if [ $? -eq 0 ]; then
209 echo -n "Restoring overwritten files from backup..."
210 cd ${TMP_DIR}/backup
211 tar -cpf - . | tar -f - -xvpC / &> /dev/null
212 okfail
213 echo
214 fi
215 }

Backups are by default enabled in checkinstall 1.5.3.

The $TMP_DIR/backup directory is created chmod 700 (it looks like it's created by installwatch):
ls -ld /var/tmp/GCZUQqPIlOGQmQcZCPbN/backup/
drwx------ 2 root root 48 2006-11-13 15:45 /var/tmp/GCZUQqPIlOGQmQcZCPbN/backup/

If ctrl-c is hit from inside checkinstall, the cleanup function is called.
The cleanup function then calls restore_backup.
If any files exist in $TMP_DIR/backup when restore_backup is called, it restores those files using the tar commands on line 211.

Line 211 tars up any files in $TMP_DIR/backup (including $TMP_DIR/backup itself), then restores those files and their permissions in /
Since $TMP_DIR/backup is chmod 700, after restoring the backup files, / will also be chmod 700

Perhaps line 211 should be changed to this?
tar -cpf - * | tar -f - -xvpC / &> /dev/null

-------------------

checkinstall 1.6.0 doesn't have this problem because translation is enabled by default:
function restore_backup {
 # If we have translation turned on then we didn't do a backup
 if [ "${TRANSLATE}" = "1" ]; then return 0; fi

 # Else, restore the backup if it exists

 rm -rf ${TMP_DIR}/BACKUP/no-backup &> /dev/null

 ls ${TMP_DIR}/BACKUP/* &> /dev/null
 if [ $? -eq 0 ]; then
    echogn "Restoring overwritten files from backup..."
    cd ${TMP_DIR}/BACKUP
       $TAR -cpf - . | $TAR -f - -xvpC / &> /dev/null
    okfail
    echo
 fi
}

However, if translation were to be disabled, the problem would resurface.

-------------------

Note that checkinstall 1.6.1 was recently released... (As far as this problem is concerned, checkinstall 1.6.1 and 1.6.0 behave the same)

-------------------

Two other unrelated bugs I came across while researching this one:

#1:
In checkinstall 1.6.0/1.6.1, due to the new translation feature, even if you tell checkinstall NOT to exclude files installed into `pwd`, it will exclude them.
The files in pwd need to be copied to the translation directory to be included in the package, but they aren't copied.
If translation is enabled, the files should be copied over (immediately after checking for files in pwd - around line 1525 in 1.6.0 - the user is given an opportunity to edit the list of files, and if the user adds any new files, those files are automatically copied if translation is enabled - but it doesn't happen unless '--inspect' is passed on the command line).

#2:
$TMP_DIR should begin with a '/' :
! [ "$BASE_TMP_DIR" ] && BASE_TMP_DIR=/var/tmp
TMP_DIR=${BASE_TMP_DIR}/`awk 'BEGIN { srand(); for (i=1;i<21;i++) { a=95; while (a > 90 && a < 97) { a=65+int(50*rand())}; printf("%c", a) } }'`

However, there are a number of places in the code where the variable is used as '/$TMP_DIR', so you end up with '//var/tmp/...'

Of course, it works ju...

Wow, thanks for tracking this bug down! I will (hopefully this week)
update to version 1.6.1, correct this bug, and forward the solution
upstream. I will look at the other things mentioned also. However,
your proposed solution:

> tar -cpf - * | tar -f - -xvpC / &> /dev/null

wouldn't work if there are dot files in the directory: bash excludes
filenames beginning with a dot when expanding *. Possibly we could use
'ls -A' to get all the files. Now that I see this, I wonder why use
tar, when cp might suffice.

--

 Felipe Sateler

I forwarded this info upstream at the same time as I submitted the info above to this bug report.
The upstream maintainer mentioned he would fix the problems, but it doesn't look like a new
upstream version has been released yet.

You're right that my proposed solution wouldn't work.
I'm not sure why tar is used instead of cp - perhaps something to do with the handling of special
files? It looks like tar is always used in the script when copying files, so I guess there is
probably a reason for it.

BTW - http://lists.debian.org/debian-mentors/2006/11/msg00008.html
I believe the reason those bugs aren't going away is because they are tagged as 'fixed in
installwatch 0.7.0beta4-1', so the BTS assumes the bug still exists in any version of checkinstall
that is installed on a system without installwatch > 0.7.0beta4-1 - and, since the installwatch
package is now gone, all versions of checkinstall are now "installed on a system without
installwatch > 0.7.0beta4-1". You would expect that the 'replaces: installwatch' tag would
automatically take care of this, but I guess not.
You probably need to re-tag those bugs as 'fixed in checkinstall 1.6.0'. Or maybe add a changelog
entry to your next update to checkinstall which closes all those bugs again.

Thanks!
-Paul

Source: checkinstall
Source-Version: 1.6.1-1

We believe that the bug you reported is fixed in the latest version of
checkinstall, which is due to be installed in the Debian FTP archive:

checkinstall_1.6.1-1.diff.gz
  to pool/main/c/checkinstall/checkinstall_1.6.1-1.diff.gz
checkinstall_1.6.1-1.dsc
  to pool/main/c/checkinstall/checkinstall_1.6.1-1.dsc
checkinstall_1.6.1-1_i386.deb
  to pool/main/c/checkinstall/checkinstall_1.6.1-1_i386.deb
checkinstall_1.6.1.orig.tar.gz
  to pool/main/c/checkinstall/checkinstall_1.6.1.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Felipe Sateler <email address hidden> (supplier of updated checkinstall package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

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

Format: 1.7
Date: Wed, 6 Dec 2006 00:02:32 -0300
Source: checkinstall
Binary: checkinstall
Architecture: source i386
Version: 1.6.1-1
Distribution: unstable
Urgency: low
Maintainer: Felipe Sateler <email address hidden>
Changed-By: Felipe Sateler <email address hidden>
Description:
 checkinstall - installation tracker
Closes: 281823 284786 342578
Changes:
 checkinstall (1.6.1-1) unstable; urgency=low
 .
   * New upstream release.
   * Tag files in /etc as conffiles
    (Closes: #284786)
   * Fix backup restoration changing permissions of the root directory.
    (Closes: #342578, #281823)
   * Fix erronous manpage sgml files.
Files:
 c9d51d994113daffef2a205efbacbbf7 608 admin optional checkinstall_1.6.1-1.dsc
 1ae49645d6d16efac79ac67b84bfb419 159552 admin optional checkinstall_1.6.1.orig.tar.gz
 d4826868b9e13c5cc8e2075572994cc7 9167 admin optional checkinstall_1.6.1-1.diff.gz
 346713570ba034409b9c1c104fa93eeb 110430 admin optional checkinstall_1.6.1-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFeGQieYl9593Atw0RAtqiAKCfPPA31c+yGvnP6DUyngin7EbbBgCbBQrM
24KQm5RhR0xwSryuLcrM7FE=
=5Ipf
-----END PGP SIGNATURE-----