Bug 1074067

Why would ntpd_t be reading a binary file in the home dir?  home_bin_t?

ntpd is started under user ntp. 
A glance at /etc/passwd shows that ntpd's home directory is /etc/ntp
The crash report shows its trying to open the directory /etc/ntp/.
presumably in an attempt to see what's there. In fact the content is:

# ls -la /etc/ntp
total 28
drwxr-xr-x.   3 root root  4096 Jan 25 17:33 .
drwxr-xr-x. 150 root root 12288 Mar  7 16:50 ..
drwxr-x---.   2 root ntp   4096 Jan 25 17:33 crypto
-rw-------.   1 root root    86 Dec  9 16:23 keys
-rw-r--r--.   1 root root    74 Dec  9 16:23 step-tickers

On that basis I'd say its entirely reasonable that it wants to know whats in the files crypto/pw, keys and step-tickers. In this case all the files have their default contents, i.e. there is nothing but comments in 'crypto/pw' and 'keys' but 'step-tickers contains the three lines between the dashes:

==============start of step-tickers===============
# List of NTP servers used by the ntpdate service.

0.fedora.pool.ntp.org
===============end of step-tickers================

Well the AVC is about name="bin" labeled as home_bin_t which means a binary file in the home dir.

Or are you getting additional AVCs?

I read the last line of the original report, 

"SELinux is preventing /usr/sbin/ntpd from 'read' accesses on the directory .",

as meaning that ntpd was reading '.' in order to see what is in its home directory. opendir() returns a stream and, as readdir() returns dirent structs, which contain binary values, its very likely that it is reading the directory as a binary file.

Additional AVCs? Not as far as I know.

ls -lZ /usr/bin

Is that labeled as home_bin_t?  Or is the a directory in your homedir named bin?

ls -lZ ~/bin

It could be ntpd reading the directories listed in your $PATH if you have ~/bin in the path?

Here's what I see under ~ntp, which is where systemd is starting ntpd:

# ls -alZ
drwxr-xr-x. root root system_u:object_r:etc_t:s0       .
drwxr-xr-x. root root system_u:object_r:etc_t:s0       ..
drwxr-x---. root ntp  system_u:object_r:ntpd_key_t:s0  crypto
-rw-------. root root system_u:object_r:ntpd_key_t:s0  keys
-rw-r--r--. root root system_u:object_r:ntp_conf_t:s0  step-tickers

This is as close as I can come to what I think you mean by "ls -lZ /usr/bin" since the /etc/passwd entry for ntp is:

# grep ntp  /etc/passwd
ntp:x:38:38::/etc/ntp:/sbin/nologin

I don't know why you're asking about my homedir, since that is not where ntpd is being run. The only thing I can think of to add is that $PATH probably contains:

# echo $PATH
/usr/java/ant/bin:/usr/java/sdk/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/java/jmf/bin:/usr/X11R6/bin:/root/bin

because I use Java from all personally created logins on this box and so have added the /etc/profile.d/java.sh file (attached) so it will be applied to the ntpd user as well.

Created attachment 875260 [details]
This is /etc/profile.d/java.sh on my system

The point is we would like to know which dir is labeled as bin_home_t. Then we can say it is a bad labeling or there is a bug in ntpd which tries to access something what is not needed.

# find  / -context "*home_bin_t*" -printf "%p %Z\n"

Gotcha. 'find' output is attached as a separate file.

/home/kiwi and /home/reference are two regular login directories which both have bin directories containing scripts.

/home/local/bin is different. It is, in fact part of the /usr/local directory structure, created by the commands "cd /home; mv /usr/local ." and then relinked by the commands "cd /usr; ln -s /home/local local" so it works as usual. I did this because /home is mounted in its own separate partition for faster clean installs when a new version of Fedora is released. This partition is not reformatted and, after the install has completed, its only necessary to run 
"cd /usr; rm -rf local; ln -s /home/local local;" to make locally developed programs and scripts available again.

Of these, only /home/local/bin should be in $PATH under its alias of /usr/local/bin when ntpd is starting up.

Created attachment 875494 [details]
'find' output as requested.

# semanage fcontext -a -e /usr /home/local
# restorecon -R -v /home/local

Should fix the labeling.