Red Hat Bugzilla – Bug 144690
sticky bit not set on /tmp and /var/tmp during kickstarts
Last modified: 2014-03-16 22:51:44 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 Description of problem: During kickstarts, the sticky bit is not set correctly on the tmp directories. We do not know if this occurs during cd installs as well. Version-Release number of selected component (if applicable): filesystem-2.2.1-3 How reproducible: Always Steps to Reproduce: 1. install via kickstart 2. 3. Actual Results: ls -ld /tmp /var/tmp argonaut> ls -ld /tmp /var/tmp drwxrwxrwx 18 root root 4096 Jan 10 13:05 /tmp/ drwxrwxrwx 3 root root 4096 Jan 7 14:36 /var/tmp/ Expected Results: argonaut> ls -ld /tmp /var/tmp drwxrwxrwt 18 root root 4096 Jan 10 13:05 /tmp/ drwxrwxrwt 3 root root 4096 Jan 7 14:36 /var/tmp/ Additional info:
Please attach the output of: rpm -qf /tmp /var/tmp
argonaut> rpm -qf /tmp /var/tmp filesystem-2.2.1-3 filesystem-2.2.1-3
Does 'rpm -V /var/tmp' show the permissions being wrong?
rpm -V filesystem, or rpm -Vf /var/tmp, you mean? Not currently, as we manually set the sticky bit on all our workstations. We'll have a few new builds out this week, and will look then.
this is off a fresh ks install: walleye> ls -ld /tmp /var/tmp drwxrwxrwx 30 root root 4096 Jan 14 16:16 /tmp/ drwxrwxrwx 2 root root 4096 Jan 14 12:19 /var/tmp/ walleye> rpm -V filesystem .M...... /tmp .M...... /var/tmp walleye> rpm -Vf /tmp /var/tmp .M...... /tmp .M...... /var/tmp .M...... /tmp .M...... /var/tmp walleye> rpm -V filesystem .M...... /tmp .M...... /var/tmp
Can you attach your install.log?
Also, are either of /tmp, /var, or /var/tmp separate partitions?
Also also, is this a particular update release?
Actually, attaching ks.cfg may also help. Sorry about the incremental bug updates. :)
Created attachment 109826 [details] install log install log attached.
Created attachment 109827 [details] kickstart config kickstart config for rhel 3ws installs we even try explicitly setting sticky bit.
taroon update 2, if I recall, then we go to update 4 after installation and reboot. Yes, /tmp and /var are on seperate partitions. These are the permissions of the underlying mount point for /tmp. /var is a little harder to unmount and ckeck remotely. drwxr-xr-x 2 root root 4096 Jan 14 17:47 /tmp Did I miss any of the incremental bug update questions? :)
Just to make sure; can you do: rpm -qvlp j2re-1_4_2_03-linux-i586.rpm | grep /tmp rpm -qp --scripts --triggers j2re-1_4_2_03-linux-i586.rpm
Created attachment 109870 [details] rpm -qp --scripts --triggers rpm -qp --scripts --triggers /var/www/html/ks/9.0/RedHat/RPMS/j2re-1_4_2_03-linux-i586.rpm >/tmp/rpm-output
rpm -qvlp j2re-1_4_2_03-linux-i586.rpm | grep tmp yielded no output
OK, the post scripts are completely overengineered, too long, and broken in places. But they shouldn't be messing the directory perms. Hm.
OK, I've done a kickstart install of U2 with partitioning as in your ks.cfg, and I can't reproduce the problem. Note that I don't have a) some of your external packages b) your %post
Just checked xv, wv, legato client, and a few others. they don't touch /tmp either. From what I've been told, this is a long-standing bug around here. And yes, sun sure does know how to write overly complex scripts.
If you just halt the installer without rebooting, does it have the right permissions then? (I realize this may be tricky to do.) Perhaps easier, if, on the first boot, you boot to single user mode - is it correct there? Since I can't reproduce it on a 'stock' install with similar partitioning, I'm wondering if something in the startup sequence is changing it.
Hmmmm ... I did a little magic, built an installation tree off U4 and latest updates, and that set the permissions correctly. I am not sure as to whether it was our explicit chmod calls in ks.cfg, or if the package installed correctly, but either way, they seem to be correct now.
OK, closing as I could never reproduce it. Please reopen if it comes back.