Bug 144690 - sticky bit not set on /tmp and /var/tmp during kickstarts
Summary: sticky bit not set on /tmp and /var/tmp during kickstarts
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: filesystem   
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-10 18:14 UTC by John Jasen
Modified: 2014-03-17 02:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-04 20:41:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
install log (29.83 KB, text/plain)
2005-01-15 21:08 UTC, John Jasen
no flags Details
kickstart config (7.58 KB, text/plain)
2005-01-15 21:19 UTC, John Jasen
no flags Details
rpm -qp --scripts --triggers (12.05 KB, text/plain)
2005-01-17 17:37 UTC, John Jasen
no flags Details

Description John Jasen 2005-01-10 18:14:37 UTC
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):

How reproducible:

Steps to Reproduce:
1. install via kickstart

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:

Comment 1 Bill Nottingham 2005-01-10 20:20:50 UTC
Please attach the output of:

rpm -qf /tmp /var/tmp

Comment 2 John Jasen 2005-01-10 23:05:43 UTC
argonaut> rpm -qf /tmp /var/tmp

Comment 3 Bill Nottingham 2005-01-11 00:11:56 UTC
Does 'rpm -V /var/tmp' show the permissions being wrong?

Comment 4 John Jasen 2005-01-11 01:50:14 UTC
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

Comment 5 John Jasen 2005-01-14 21:47:56 UTC
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

Comment 6 Bill Nottingham 2005-01-14 23:02:08 UTC
Can you attach your install.log?

Comment 7 Bill Nottingham 2005-01-14 23:05:35 UTC
Also, are either of /tmp, /var, or /var/tmp separate partitions?

Comment 8 Bill Nottingham 2005-01-14 23:08:28 UTC
Also also, is this a particular update release?

Comment 9 Bill Nottingham 2005-01-14 23:20:15 UTC
Actually, attaching ks.cfg may also help. Sorry about the incremental
bug updates. :)

Comment 10 John Jasen 2005-01-15 21:08:36 UTC
Created attachment 109826 [details]
install log

install log attached.

Comment 11 John Jasen 2005-01-15 21:19:57 UTC
Created attachment 109827 [details]
kickstart config

kickstart config for rhel 3ws installs

we even try explicitly setting sticky bit.

Comment 12 John Jasen 2005-01-15 21:25:38 UTC
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? :)

Comment 13 Bill Nottingham 2005-01-17 17:23:24 UTC
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

Comment 14 John Jasen 2005-01-17 17:37:00 UTC
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

Comment 15 John Jasen 2005-01-17 17:37:39 UTC
rpm -qvlp j2re-1_4_2_03-linux-i586.rpm | grep tmp yielded no output

Comment 16 Bill Nottingham 2005-01-17 19:29:38 UTC
OK, the post scripts are completely overengineered, too long, and
broken in places. But they shouldn't be messing the directory perms. Hm.

Comment 17 Bill Nottingham 2005-01-17 20:16:31 UTC
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

Comment 18 John Jasen 2005-01-17 20:35:57 UTC
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.

Comment 19 Bill Nottingham 2005-01-21 23:11:13 UTC
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.

Comment 20 John Jasen 2005-02-04 20:37:38 UTC
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.

Comment 21 Bill Nottingham 2005-02-04 20:41:39 UTC
OK, closing as I could never reproduce it. Please reopen if it comes back.

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