Bug 149114 - Multiple same specifications for two /var patterns
Summary: Multiple same specifications for two /var patterns
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
: 150466 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-18 21:50 UTC by Jerry James
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-12 18:51:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
file_contexts file with multiple same /var patterns (34.84 KB, text/plain)
2005-03-01 16:37 UTC, Jerry James
no flags Details
fix home_root_t logic in genhomedircon (3.97 KB, patch)
2005-03-08 19:13 UTC, Eric Paris
no flags Details | Diff
A cleanup on the last patch. Should be little more maintainable (4.68 KB, patch)
2005-03-09 23:00 UTC, Eric Paris
no flags Details | Diff
newest iteration (4.69 KB, patch)
2005-03-10 00:37 UTC, Eric Paris
no flags Details | Diff
Hopefully last???? (5.05 KB, patch)
2005-03-10 01:04 UTC, Eric Paris
no flags Details | Diff

Description Jerry James 2005-02-18 21:50:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

Description of problem:
Upgrading to selinux-policy-targeted-1.17.30-2.80 causes every use of rpm to report:

WARNING: Multiple same specifications for /var/lost\+found(/.*)?.
WARNING: Multiple same specifications for /var/\.journal.

This is because /etc/selinux/targeted/contexts/files/file_contexts in fact contains two identical entries for those two patterns.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Upgrade to selinux-policy-targeted-1.17.30-2.80
2. Use rpm to install or upgrade some package.

Actual Results:  I got the described warnings.

Expected Results:  No warnings.

Additional info:

Comment 1 Jerry James 2005-02-25 15:42:37 UTC
This is still true of the just released selinux-policy-targeted-1.17.30-2.83.

Comment 2 Daniel Walsh 2005-02-28 15:22:32 UTC
Do you have users accounts in /var?


Comment 3 Jerry James 2005-02-28 19:22:32 UTC
No, but I administer my machine via sudo.  Could upgrading
selinux-policy-targeted via "sudo rpm" cause this problem?

Comment 4 Daniel Walsh 2005-02-28 20:06:58 UTC
Do you have selinux-policy-targeted-sources installed?

Could you attach your /etc/selinux/targeted/contexts/files/file_context file


Comment 5 Jerry James 2005-03-01 16:37:55 UTC
Created attachment 111531 [details]
file_contexts file with multiple same /var patterns

Yes, I have selinux-policy-targeted-sources installed.	I am attaching the
file_contexts file from the affected machine.  I see that an attempt is being
made to extract home directories from /etc/passwd.  In my /etc/passwd there are
entries like this (changed slightly due to my paranoia):

enable:x:30:40:Enable CVS User:/projects/enable:/bin/tcsh
apache2:x:50:60:Apache Web Server:/usr/local/etc/httpd:/bin/tcsh

which is how those directories are getting picked up, apparently.

Comment 6 Daniel Walsh 2005-03-01 16:45:01 UTC
Could you change the shell accounts to /sbin/nologin  I don't think you want to
login to those accounts.  

Afterwards run
make -C /etc/selinux/targeted/src/policy reload

Does that remove the duplicates

Comment 7 Jerry James 2005-03-02 15:16:31 UTC
Unfortunately, I can't do that.  I'm just a Joe User here, although the
sysadmins let me upgrade packages with sudo.  I'll have to ask the sysadmins to
do this.  The answer might be no if they think they have a good reason for those
shells.  In any case, can't you filter /var out of the list of paths generated
from /etc/passwd?  That would prevent this from happening to other people in a
similar situation.

Comment 8 David Kewley 2005-03-03 03:40:07 UTC
I have a somewhat related problem on FC3.  At one point, I installed  
netdump-server (recently I uninstalled it, but that doesn't affect this  
issue).  It has this nifty bit of code snipped from its %pre script:  
/usr/sbin/useradd -c "Network Crash Dump user" -r -u 34 -g netdump \  
    -s /bin/bash -r -d /var/crash netdump 2>/dev/null || :  
Sure enough, in /etc/passwd I have:  
netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash  
and in /etc/selinux/targeted/contexts/files/file_contexts I have:  
/var/[^/]+              -d      system_u:object_r:user_home_dir_t  
This caused several daemons (named, syslogd, portmap, ypbind, ntpd) to get avc  
denied errors on reboot, e.g.:  
Mar  2 18:03:49 geyser kernel: audit(1109815429.248:0): avc:  denied  { search  
} for  pid=3399 exe=/sbin/syslogd name=var dev=dm-0 ino=4194433  
scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:home_root_t  
Given that I trustingly updated the policy rpm Saturday, and my logs got  
rotated Sunday, my new logs were empty until I put the machine in permissive  
mode this evening.  More seriously, I rebooted the machine remotely this  
evening (but sitting in the same building, so I was able to run over and  
debug), leaving the machine in enforcing mode, and it took several minutes  
longer than normal to come up fully, I suppose because e.g. sylogd was  
spinning until timeout.  
I've removed all traces of netdump from /etc/{passwd,shadow,group,gshadow},  
ran the 'make' you suggested above.  After reboot I still got these errors.   
Tracing this back through the various layers, I see that's because we are  
using NIS, and NIS has a user 'postman' with home /var/postman.  
Is HOME_ROOT a new feature in selinux, or in the targeted policy, as it seems?   
It seems to me its presence carries a big risk: Anyone or any rpm that creates  
a user with a valid shell but an inopportune home directory, may cause avc  
denied failures, perhaps severe ones.  You've suddenly saddled sysadmins, rpm  
authors, and authentication database maintainers with a new, critical  
responsibility, one that I wasn't aware of.  Should I have been aware of it?  
Whaddya think, Dan?  Hope I'm not blowing this out of proportion; I'm a 
capable sysadmin, but a relative newbie to selinux. 

Comment 9 Daniel Walsh 2005-03-07 15:02:00 UTC
Ok can you run genhomedircon and take a look at

That should remove the secondary definition of /var?  

We have a newer version of genhomedircon in rawhide that I will begin to back
port since this seems to be a larger problem than first thought.  Some users
might have a legitimate reason for putting users in /var and the scripts should
be able to handle this.


Comment 10 Jerry James 2005-03-07 21:57:00 UTC
I wasn't sure what parameters to pass to genhomedircon, so from
/etc/selinux/targeted, I did this:

genhomedircon src contexts/files/file_contexts

The output that produces does not, in fact, have the duplicate /var patterns.

While checking on this, I also discovered that load_policy has dumped core into
/etc/selinux/targeted/src/policy every time I have logged in from the console
since Feb. 18, the day I made the initial report.  Since that is a protected
directory, I didn't know those core files were there until I started poking
around with sudo.  The backtraces all look like this:

(gdb) bt
#0  0x006fe7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0073e955 in raise () from /lib/tls/libc.so.6
#2  0x00740319 in abort () from /lib/tls/libc.so.6
#3  0x00737f41 in __assert_fail () from /lib/tls/libc.so.6
#4  0x004d3570 in security_get_boolean_names (names=0x0, len=0xbfe22bfc)
    at booleans.c:48
#5  0x08048bc9 in main (argc=2, argv=0xbfe22d04) at load_policy.c:96
#6  0x0072be33 in __libc_start_main () from /lib/tls/libc.so.6
#7  0x08048891 in _start ()

I should note that I have all the selinux packages installed, but it is
currently turned off at boot time.

Comment 11 Daniel Walsh 2005-03-08 16:09:43 UTC
Could you open a separate bug on this?  
Otherwise it will get lost in the shuffle.  


Comment 12 David Kewley 2005-03-08 16:19:26 UTC
I now realize that netdump-server would not cause a problem because its custom  
user is uid 34 < 100.  I'm still getting a problem because we have in NIS:  
  postman:*LK*:30020:111:Postman user:/var/postman:/bin/sh  
I don't know if this configuration is correct or desireable any longer, but it  
is our legacy situation.  
To follow up on your latest test request, I just now did:  
[root@geyser files]# pwd  
[root@geyser files]# rpm -q selinux-policy-targeted  
[root@geyser files]# genhomedircon ../../src file_contexts |grep var | head -6  
# this is /var/run/utmp.  
/var            -d      system_u:object_r:home_root_t  
/var/[^/]+              -d      system_u:object_r:user_home_dir_t  
/var/[^/]+/.+                   system_u:object_r:user_home_t  
# /var  
/var(/.*)?                      system_u:object_r:var_t  
So yeah, I still have a problem. :)  
A sane, knowledgeable sysadmin would set selinux in permissive mode before  
updating policy, then see what errors (if any) are generated upon reboot after  
policy update.  And that sysadmin would catch things like this, presumably.   
But a lot of us aren't that knowledgeable yet about selinux, so might get  
bitten like I did.  No damage (except DoS), but a bit frustrating.  I suppose 
remote admins might have more trouble. 

Comment 13 Eric Paris 2005-03-08 19:13:15 UTC
Created attachment 111786 [details]
fix home_root_t logic in genhomedircon

Here is my first hack to fix the logic in /usr/sbin/genhomedircontexts against

Comment 14 David Kewley 2005-03-08 22:57:44 UTC
Eric, your patch still created a home_root_t entry for /var in my environment.  
Is there something I can do to give you more detailed feedback? 

Comment 15 Eric Paris 2005-03-08 23:04:38 UTC
Can you give me a copy of /etc/passwd (relevant line) /etc/default/useradd
/etc/libuser.conf?   And let me know how you regenerate?   Did you use the
makefile or run genhomedircon by hand?

Comment 16 Eric Paris 2005-03-09 23:00:47 UTC
Created attachment 111827 [details]
A cleanup on the last patch.  Should be little more maintainable

This patch watchs both /etc/libuser.conf and /etc/login.defs for minimum login.
 It removes some uses of sed since the create error checking problem and
instead uses the python internal re module.  This patch also fixes the logic in
the last patch where a user could define HOME=/var in /etc/default/useradd and
the /var directory would become improperly labeled.

Comment 17 Eric Paris 2005-03-10 00:37:43 UTC
Created attachment 111835 [details]
newest iteration

Comment 18 Eric Paris 2005-03-10 01:04:58 UTC
Created attachment 111836 [details]
Hopefully last????

Found that a stategically placed comment in /etc/default/useradd,
/etc/libuser.conf, or /etc/login.defs could cause the script to fail.

Comment 19 Daniel Walsh 2005-03-10 20:47:16 UTC
*** Bug 150466 has been marked as a duplicate of this bug. ***

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