Description of problem: repopatch will fail to upgrade the repositories if the directory /tmp/kusu does nto exist. The program should check for the existence and recreate if the dir was e.g. deleted during a cleanup script. Details: [root@installer ~]# repopatch -r rhel5_x86_64 Getting updates for rhel-5-x86_64. This may take a while... New kernel(s) found: kernel-2.6.18-92.1.10.el5.x86_64.rpm kernel-debug-2.6.18-92.1.10.el5.x86_64.rpm kernel-debug-devel-2.6.18-92.1.10.el5.x86_64.rpm kernel-devel-2.6.18-92.1.10.el5.x86_64.rpm kernel-doc-2.6.18-92.1.10.el5.noarch.rpm kernel-headers-2.6.18-92.1.10.el5.x86_64.rpm kernel-xen-2.6.18-92.1.10.el5.x86_64.rpm kernel-xen-devel-2.6.18-92.1.10.el5.x86_64.rpm Do you wish to include them? (Yes or No): yes Making new update kit. Unable to add update kit. Reason: [Errno 2] No such file or directory: '/tmp/kusu/repopatch_buildkit2L1Lad' [root@installer ~]#
The mere existence/use of a hard-coded path in /tmp sounds very ominous to me from a security standpoint. Has this already been reviewed? NB: I don't know how many packages are affected by this (if this is a problem).
If I understand right, the 3rd level directory (in this case repopatch_buildkit2L1Lad) is created with a unique name for each run. It is just the higher level directory that needs to exist. For /tmp that can not be assumed as cleanup-scripts often delete such directories.
I don't know if the second level directory being random makes much difference. The first could be a symlink to somewhere else and that needs reviewing IMO.
Good point. Perhaps it would be easy to just remove the second level directory: it does not add any real value, does it?
The solution has two parts: 1. Update the kusu-core package. It needs to be 5.1-9. Prior to that it was using /tmp/kusu for the KUSU_TMP. Updating this package has been verified to work. 2. The second part of the solution will be in kusu-repoman 5.1-7 and this changes the value used when KUSU_TMP is undefined. A new srpm will be provided shortly.
Fix passes QA