Ian,
could you explain why does automount need the capability dac_override?

This is kind of bad as it completely prevents autofs from functioning, which breaks a rather important portion of the /home-on-NFS use case.  Is there any way the community can help to move this forward?  I'm afraid I can't explain why autofs might need dac_override, except that perhaps it still needs to be able to examine the directories on which the remote filesystems are mounted regardless of the permissions assigned to them once the mount happen (which come from the remote machine).  But that's just a random guess.

Is there any way someone who isn't familiar with autofs internals can answer this question?  I asked on the IRC channel where the NFS devs hang out but I'm not sure they're really aware of autofs internals.

*** Bug 1512822 has been marked as a duplicate of this bug. ***

(In reply to Lukas Slebodnik from comment #1)
> Ian,
> could you explain why does automount need the capability dac_override?

Can someone explain exactly what dac_override is?

The selinux implementation as it relates to autofs is a mystery
to me. In fact when I have been asked for information about autofs
and selinux I haven't been able to get useful information, it
appears the implementation is a mystery to selinux folks as well.

There's a problem with this .....

(In reply to Jason Tibbitts from comment #2)
> This is kind of bad as it completely prevents autofs from functioning, which
> breaks a rather important portion of the /home-on-NFS use case.  Is there
> any way the community can help to move this forward?  I'm afraid I can't
> explain why autofs might need dac_override, except that perhaps it still
> needs to be able to examine the directories on which the remote filesystems
> are mounted regardless of the permissions assigned to them once the mount
> happen (which come from the remote machine).  But that's just a random guess.

Whether access is needed (and access to what) isn't a simple question.

And your description sounds like it's talking about local directories
within the autofs file system (mount points) which would be the case
for simple indirect autofs maps. Direct autofs mount maps mount each
mount trigger onto directories within the local file system (usually).

There doesn't appear to be any context in this bug report that I can
use to try and work out what's going on.

And why has this changed after such a long time?

I'm pretty ignorant about the whole issue, but what I've been able to gather is that there's a task capability CAP_DAC_OVERRIDE, and relatively recently in rawhide, Fedora's selinux policy has started restricting the use of that.  When it blocks an attempt, you see an AVC referencing dac_override.  I believe it's possible to turn up the auditing level to get the path it's trying to access, but I haven't tried that.

Of course, I don't see anything related to CAP_DAC_OVERRIDE in the autofs source.  I see only mention of CAP_SYS_ADMIN, and then only in the patches directory.  So, honestly, I have basically no concept of what's really going on.

I heard back from Jeff Layton on IRC who suggested that the capability may be needed to create directories within a mount hierarchy so that remote filesystems can be mounted on them.  Since autofs runs as root, I'm not sure why it can't just do that anyway, but of course I'm missing a whole lot of the picture.

He also suggested that it may be possible to get away with just CAP_DAC_READ_SEARCH, but I have no idea if that would work, and also no idea if selinux would be any happier with it.  And even then, if autofs actually needs CAP_SYS_ADMIN then restricting CAP_DAC_OVERRIDE is kind of pointless.

(In reply to Jason Tibbitts from comment #6)
> I'm pretty ignorant about the whole issue, but what I've been able to gather
> is that there's a task capability CAP_DAC_OVERRIDE, and relatively recently
> in rawhide, Fedora's selinux policy has started restricting the use of that.
> When it blocks an attempt, you see an AVC referencing dac_override.  I
> believe it's possible to turn up the auditing level to get the path it's
> trying to access, but I haven't tried that.

I had a quick look too.
So there's does seem to be a policy change I need to consider.

> 
> Of course, I don't see anything related to CAP_DAC_OVERRIDE in the autofs
> source.  I see only mention of CAP_SYS_ADMIN, and then only in the patches
> directory.  So, honestly, I have basically no concept of what's really going
> on.

Those patches are very old, they really don't relate to
the current kernel any more, and they don't really relate
to the daemon either.

I think we can ignore them.

autofs kernel access is either by ioctl (and should be via
the /dev/autofs miscellaneous device) or requests generated
by path walks, don't now if this figures in the denials.

> 
> I heard back from Jeff Layton on IRC who suggested that the capability may
> be needed to create directories within a mount hierarchy so that remote
> filesystems can be mounted on them.  Since autofs runs as root, I'm not sure
> why it can't just do that anyway, but of course I'm missing a whole lot of
> the picture.

Probably not, but I may have messed that up at some point.

A long time ago autofs was changed to require remote mount
point directories (eg directories within an NFS mount)
already exist. The idea being that autofs itself should not
need excessive permissions on remote file systems and should
not mess with them at all.

It does need to check existence, as you'd expect.
Perhaps it is the way in which this is done that is at fault?

> 
> He also suggested that it may be possible to get away with just
> CAP_DAC_READ_SEARCH, but I have no idea if that would work, and also no idea
> if selinux would be any happier with it.  And even then, if autofs actually
> needs CAP_SYS_ADMIN then restricting CAP_DAC_OVERRIDE is kind of pointless.

I think we need to know what paths are causing the AVCs.
I think that's the only way to get a lead on what autofs code
is not behaving.

Ian

I found an entry in dwalsh's blog from a few years back which talks about this:
http://danwalsh.livejournal.com/69478.html

I tried following the directions in a linked entry which talks about upping the audit logging to get information about the paths involved, but it doesn't work for me.  Talks about "service auditd restart" which of course is pre-systemd.  And systemd doesn't actually let you restart audit for whatever reason.  Plus /etc/audit/audit.rules is autogenerated, so I added the suggest rule ("-w /etc/shadow -p w" to a file in /etc/audit/rules.d and restarted the system.

I don't see any change in the output, so I still have no idea what the problematic path is.  Hopefully one of the selinux folks can give some hints about this; some good documentation would really help here.  As it is, I'm pretty much lost.

(In reply to Jason Tibbitts from comment #8)
> I found an entry in dwalsh's blog from a few years back which talks about
> this:
> http://danwalsh.livejournal.com/69478.html
> 
> I tried following the directions in a linked entry which talks about upping
> the audit logging to get information about the paths involved, but it
> doesn't work for me.  Talks about "service auditd restart" which of course
> is pre-systemd.  And systemd doesn't actually let you restart audit for
> whatever reason.  Plus /etc/audit/audit.rules is autogenerated, so I added
> the suggest rule ("-w /etc/shadow -p w" to a file in /etc/audit/rules.d and
> restarted the system.
> 
> I don't see any change in the output, so I still have no idea what the
> problematic path is.  Hopefully one of the selinux folks can give some hints
> about this; some good documentation would really help here.  As it is, I'm
> pretty much lost.

Perhaps an debug log will show access denied messages?

You should be able to set "logging = debug" in /etc/autofs.conf
and restart autofs to get debug output.

With systemd I've found the best way to get the debug log output
is something like "journalctl -xe|grep automount" or perhaps use
-ae can't remember, but give it a try anyway.

Ian

Sorry, autofs doesn't log anything additional when you turn up its debugging output.  I don't think it's getting very far into its startup at all.

(In reply to Jason Tibbitts from comment #10)
> Sorry, autofs doesn't log anything additional when you turn up its debugging
> output.  I don't think it's getting very far into its startup at all.

Did you get anything?

Not really anything useful.  This is just after a fresh boot.

[root@test-rawhide ~]# journalctl -b |egrep 'autofs|automount'
Dec 18 20:46:10 test-rawhide.e.math.uh.edu sssd[autofs][844]: Starting up
Dec 18 20:46:11 test-rawhide.e.math.uh.edu audit[891]: AVC avc:  denied  { dac_override } for  pid=891 comm="automount" capability=1  scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=0
Dec 18 20:46:11 test-rawhide.e.math.uh.edu audit[891]: AVC avc:  denied  { dac_override } for  pid=891 comm="automount" capability=1  scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=0
Dec 18 20:46:11 test-rawhide.e.math.uh.edu automount[882]: /usr/sbin/automount: program is already running.
Dec 18 20:46:11 test-rawhide.e.math.uh.edu audit[532]: AVC avc:  denied  { read } for  pid=532 comm="systemd-journal" name="invocation:autofs.service" dev="tmpfs" ino=22999 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=lnk_file permissive=0
Dec 18 20:46:11 test-rawhide.e.math.uh.edu audit: PATH item=0 name="/run/systemd/units/invocation:autofs.service" inode=22999 dev=00:16 mode=0120777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:init_var_run_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
Dec 18 20:46:11 test-rawhide.e.math.uh.edu systemd[1]: autofs.service: PID file /run/autofs.pid not readable (yet?) after start: No such file or directory
Dec 18 20:46:11 test-rawhide.e.math.uh.edu systemd[1]: autofs.service: Failed with result 'protocol'.
Dec 18 20:46:11 test-rawhide.e.math.uh.edu audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=autofs comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

If I setenforce 0 and try to start autofs then I get plenty of logged output, so the debug statement is certainly working.  When this happens, only the single dac_override AVC is logged.

Of course if root just runs autofs everything works, so I can't just strace it to see exactly where it dies.

(In reply to Jason Tibbitts from comment #12)
> Not really anything useful.  This is just after a fresh boot.

But this is useful.

I also installed a Rawhide compose of 20171218.n.0 and found
that automount is completely crippled by the current selinux
policy.

> 
> [root@test-rawhide ~]# journalctl -b |egrep 'autofs|automount'
> Dec 18 20:46:10 test-rawhide.e.math.uh.edu sssd[autofs][844]: Starting up
> Dec 18 20:46:11 test-rawhide.e.math.uh.edu audit[891]: AVC avc:  denied  {
> dac_override } for  pid=891 comm="automount" capability=1 
> scontext=system_u:system_r:automount_t:s0
> tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=0
> Dec 18 20:46:11 test-rawhide.e.math.uh.edu audit[891]: AVC avc:  denied  {
> dac_override } for  pid=891 comm="automount" capability=1 
> scontext=system_u:system_r:automount_t:s0
> tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=0
> Dec 18 20:46:11 test-rawhide.e.math.uh.edu automount[882]:
> /usr/sbin/automount: program is already running.

This message appears to result from automount(8) failing to be able
to check a flag file /run/autofs-running (when it is running as uid
0) that indicates whether it is already running.

I'm not sure what the actual denial is but the function does a
fair amount of stuff to establish if the file is stale and valid
to avoid false positives.

In any case, using the "-C" option to automount bypasses the
check altogether.

Then you will see that automount(8) "as root" is unable to
create mount point directories of /net and /misc as specified
in the default installed master map.

There were other denials which looked like it couldn't read
/etc/auto.master but clearly it did read that file because
it got the master map entries, /net and /misc.

Someone is going to have to tell me what is expected of
automount(8) so that the current selinux doesn't cripple
it.

Ian

(In reply to Ian Kent from comment #13)
> 
> Someone is going to have to tell me what is expected of
> automount(8) so that the current selinux doesn't cripple
> it.

So I think the dac_override AVC on the flag file is due
to the flag file being created with a mode of 0, I'll
change that.

And I think the failure to start the automounts is due to
/ having a permission of 0555 thereby preventing autofs
from creating its top level mount point directories when
started by systemd.

autofs mount point directories themselves are created with
a permission of 0555. I think that will cause problems for
more complex map entries that create sub-directories within
the autofs mount point so I'll probably need to change that
too.

I think some input from others is on my observations is
needed now.

Also, after changing the autofs permissions above and setting
/ u+w I still see quite a few of these:
Dec 19 04:34:38 hp-dl980g7-02.khw.lab.eng.bos.redhat.com audit[1721]: AVC avc:  denied  { read } for  pid=1721 comm="systemd-journal" name="invocation:session-1.scope" dev="tmpfs" ino=118839 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=lnk_file permissive=0
Dec 19 04:34:38 hp-dl980g7-02.khw.lab.eng.bos.redhat.com audit[1721]: SYSCALL arch=c000003e syscall=267 success=no exit=-13 a0=ffffff9c a1=7ffd98d89f10 a2=557cb00fc2b0 a3=63 items=1 ppid=1 pid=1721 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-journal" exe="/usr/lib/systemd/systemd-journald" subj=system_u:system_r:syslogd_t:s0 key=(null)
Dec 19 04:34:38 hp-dl980g7-02.khw.lab.eng.bos.redhat.com audit: CWD cwd="/"
Dec 19 04:34:38 hp-dl980g7-02.khw.lab.eng.bos.redhat.com audit: PATH item=0 name="/run/systemd/units/invocation:session-1.scope" inode=118839 dev=00:17 mode=0120777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:init_var_run_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
Dec 19 04:34:38 hp-dl980g7-02.khw.lab.eng.bos.redhat.com audit: PROCTITLE proctitle="/usr/lib/systemd/systemd-journald"

I would think an AVC from systemd-journal would be rather a separate thing; look too closely at the audit log and you'll see all sorts of troubling things, especially in rawhide.  The other things appear to be regular audit log entries.

At this point, though, I would have to think that Lukas has to have enough information to answer his initial question of why autofs needs CAP_DAC_OVERRIDE.  Really I think this was more a case of asking if the selinux policy really needs to allow it, and the answer certainly does seem to be "yes".

Certainly it's reasonable to ask if autofs can work without that, and maybe it can.  But right now we have a broken autofs, and certainly that has to get fixed one way or the other before we get too far into the F28 release process.

(In reply to Jason Tibbitts from comment #15)
> I would think an AVC from systemd-journal would be rather a separate thing;
> look too closely at the audit log and you'll see all sorts of troubling
> things, especially in rawhide.  The other things appear to be regular audit
> log entries.

I hope so.

> 
> At this point, though, I would have to think that Lukas has to have enough
> information to answer his initial question of why autofs needs
> CAP_DAC_OVERRIDE.  Really I think this was more a case of asking if the
> selinux policy really needs to allow it, and the answer certainly does seem
> to be "yes".

Ideally, yes, these mount point directories are meant to
be user configurable so they are arbitrary. While the common
use case sees only a few distinct top level directories that
might not be the case.

> 
> Certainly it's reasonable to ask if autofs can work without that, and maybe
> it can.  But right now we have a broken autofs, and certainly that has to
> get fixed one way or the other before we get too far into the F28 release
> process.

If autofs can't create a mount point then it has nothing to
mount onto. I don't see a way around that.

If you have time create the mount point directories you need
before starting autofs and see if that works around the problem.
If the full autofs mount point path already exists at startup
it should not try and remove it at shutdown.

Ian

I have always pre-created all of the top level mount directories I use; I didn't think it was possible to do otherwise. On the system in question:

[root@test-rawhide ~]# cat /etc/auto.master
/net     -hosts
/home    auto.home
/nas     auto.nas
/shared  auto.shared
/storage auto.storage
/www     auto.www
+dir:/etc/auto.master.d

[root@test-rawhide ~]# ls -ld /net /home /nas /shared /storage /www
drwxr-xr-x. 2 root root 6 Dec 14 11:14 /home
drwxr-xr-x. 2 root root 6 Dec 19  2016 /nas
drwxr-xr-x. 2 root root 6 Jan  5  2017 /net
drwxr-xr-x. 2 root root 6 Jan  5  2017 /shared
drwxr-xr-x. 2 root root 6 Dec 19  2016 /storage
drwxr-xr-x. 2 root root 6 Jan  5  2017 /www

I'm pretty sure you weren't suggesting I create the directories below those.

(In reply to Jason Tibbitts from comment #17)
> I have always pre-created all of the top level mount directories I use; I
> didn't think it was possible to do otherwise. On the system in question:

LOL, right, autofs should try and create them if they don't exist
but then it will also try and remove them at shutdown.

> 
> [root@test-rawhide ~]# cat /etc/auto.master
> /net     -hosts
> /home    auto.home
> /nas     auto.nas
> /shared  auto.shared
> /storage auto.storage
> /www     auto.www
> +dir:/etc/auto.master.d
> 
> [root@test-rawhide ~]# ls -ld /net /home /nas /shared /storage /www
> drwxr-xr-x. 2 root root 6 Dec 14 11:14 /home
> drwxr-xr-x. 2 root root 6 Dec 19  2016 /nas
> drwxr-xr-x. 2 root root 6 Jan  5  2017 /net
> drwxr-xr-x. 2 root root 6 Jan  5  2017 /shared
> drwxr-xr-x. 2 root root 6 Dec 19  2016 /storage
> drwxr-xr-x. 2 root root 6 Jan  5  2017 /www
> 
> I'm pretty sure you weren't suggesting I create the directories below those.

So it still fails to start ... I'll need to check on that.

I have updated Fedora autofs to the newly released 5.1.4 and
added the changes I identified in comment #14. This release
should result in a cleaner startup and ixes a couple of
annoying regressions present in 5.1.3.

We'll need to use that revision for testing as soon as its
available.

Ian

(In reply to Ian Kent from comment #18)
> > 
> > I'm pretty sure you weren't suggesting I create the directories below those.

That's right.

> 
> So it still fails to start ... I'll need to check on that.
> 
> I have updated Fedora autofs to the newly released 5.1.4 and
> added the changes I identified in comment #14. This release
> should result in a cleaner startup and ixes a couple of
> annoying regressions present in 5.1.3.

Using the above 5.1.4 release and creating the mount point
directories I was able to successfully start autofs. I can't
really test further without checking out another lab machine
and configuring it as an NFS server.

It's not viable to require the full mount point path for all
mount points be pre-created, for example customer direct mount
maps may have tens, hundreds or thousands of entries in their
map all of which are distinct mount point paths.

It might be viable to require the top level path component
already exist so that directory creation in the root directory
is not attempted.

That will require further changes to autofs as the current code
works based on the full path existence or not.

Does this feature really mean that much to Fedora that I
should be looking at changes like this rather than an
selinux exception?

Ian

(In reply to Jason Tibbitts from comment #15)
> At this point, though, I would have to think that Lukas has to have enough
> information to answer his initial question of why autofs needs
> CAP_DAC_OVERRIDE.  Really I think this was more a case of asking if the
> selinux policy really needs to allow it, and the answer certainly does seem
> to be "yes".
> 

FYI you can create your own SELinux policy module quite easily
as a temporary workaround rather then running in permissive mode.

sh# echo '(allow automount_t self(capability(dac_override)))' > /tmp/autofs_workaround.cil
sh# semodule -i /tmp/autofs_workaround.cil

Yes, of course it's trivial to work around this on my end; I already have it in my ansible setup.  Though I really need to learn more about .cil files instead of the audit2allow method I'm accustomed to.

I just wanted to make sure that it gets fixed properly (by whichever means the experts decide is most appropriate) so that things work out of the box in F28.

(In reply to Jason Tibbitts from comment #21)
> Yes, of course it's trivial to work around this on my end; I already have it
> in my ansible setup.  Though I really need to learn more about .cil files
> instead of the audit2allow method I'm accustomed to.
>
It is quite convenient for testing because you just need to write text file.
I mostly check examples/tests on github
https://github.com/SELinuxProject/cil/

> I just wanted to make sure that it gets fixed properly (by whichever means
> the experts decide is most appropriate) so that things work out of the box
> in F28.

+1 and I would prefer to solve it on autofs side if possible and reduce required capabilities. Then it might be simpler to "containerize" it :-)

(In reply to Lukas Slebodnik from comment #22)
> 
> > I just wanted to make sure that it gets fixed properly (by whichever means
> > the experts decide is most appropriate) so that things work out of the box
> > in F28.
> 
> +1 and I would prefer to solve it on autofs side if possible and reduce
> required capabilities. Then it might be simpler to "containerize" it :-)

I have done the analysis and posted the results as well as
applying changes that are sensible as a result of the analysis.

What is it you are expecting from me?

I would like to test autofs on rawhide but "automount -m" does not work for me
with autofs-5.1.4-4.fc28.x86_64. I need to use "ctrl-C" few times.

[root@vm-058 ~]# automount -m
^C100000000|mount_init: mount(bind): umount failed for /tmp/autoZgBF7t

autofs dump map information
===========================

global options: none configured

Mount point: /misc

source(s):
^C100000000|mount_init: mount(bind): umount failed for /tmp/auto8BV2OB

  instance type(s): file 
  map: /etc/auto.misc

  cd | -fstype=iso9660,ro,nosuid,nodev  :/dev/cdrom


Mount point: /net

source(s):
^C100000000|mount_init: mount(bind): umount failed for /tmp/autoR5ejwM

  type: hosts

  rhev-01.example.com | (null)
  hector.example.com | (null)
  albina.example.com | (null)
  localhost | (null)


Mount point: /home

source(s):
^C100000000|mount_init: mount(bind): umount failed for /tmp/autoeKCAxZ

  instance type(s): file 
  map: /etc/auto.home

  * | -rw,intr,vers=3    rhev-01.example.com:/mnt/home/&


I think it might be related to some deadlock in dumpmaps (bz1527815)

Could you provide fixed version?

(In reply to Lukas Slebodnik from comment #24)
> I would like to test autofs on rawhide but "automount -m" does not work for
> me
> with autofs-5.1.4-4.fc28.x86_64. I need to use "ctrl-C" few times.
> 
> [root@vm-058 ~]# automount -m
> ^C100000000|mount_init: mount(bind): umount failed for /tmp/autoZgBF7t
> 
> autofs dump map information
> ===========================
> 
> global options: none configured
> 
> Mount point: /misc
> 
> source(s):
> ^C100000000|mount_init: mount(bind): umount failed for /tmp/auto8BV2OB
> 
>   instance type(s): file 
>   map: /etc/auto.misc
> 
>   cd | -fstype=iso9660,ro,nosuid,nodev  :/dev/cdrom
> 
> 
> Mount point: /net
> 
> source(s):
> ^C100000000|mount_init: mount(bind): umount failed for /tmp/autoR5ejwM
> 
>   type: hosts
> 
>   rhev-01.example.com | (null)
>   hector.example.com | (null)
>   albina.example.com | (null)
>   localhost | (null)
> 
> 
> Mount point: /home
> 
> source(s):
> ^C100000000|mount_init: mount(bind): umount failed for /tmp/autoeKCAxZ
> 
>   instance type(s): file 
>   map: /etc/auto.home
> 
>   * | -rw,intr,vers=3    rhev-01.example.com:/mnt/home/&
> 
> 
> I think it might be related to some deadlock in dumpmaps (bz1527815)
> 
> Could you provide fixed version?

I'll check this out as soon s I can, thanks.
Ian

(In reply to Ian Kent from comment #25)
> (In reply to Lukas Slebodnik from comment #24)
> > I would like to test autofs on rawhide but "automount -m" does not work for
> > me
> > with autofs-5.1.4-4.fc28.x86_64. I need to use "ctrl-C" few times.
> > 
> > [root@vm-058 ~]# automount -m
> > ^C100000000|mount_init: mount(bind): umount failed for /tmp/autoZgBF7t
> > 
> > autofs dump map information
> > ===========================
> > 
> > global options: none configured
> > 
> > Mount point: /misc
> > 
> > source(s):
> > ^C100000000|mount_init: mount(bind): umount failed for /tmp/auto8BV2OB
> > 
> >   instance type(s): file 
> >   map: /etc/auto.misc
> > 
> >   cd | -fstype=iso9660,ro,nosuid,nodev  :/dev/cdrom
> > 
> > 
> > Mount point: /net
> > 
> > source(s):
> > ^C100000000|mount_init: mount(bind): umount failed for /tmp/autoR5ejwM
> > 
> >   type: hosts
> > 
> >   rhev-01.example.com | (null)
> >   hector.example.com | (null)
> >   albina.example.com | (null)
> >   localhost | (null)
> > 
> > 
> > Mount point: /home
> > 
> > source(s):
> > ^C100000000|mount_init: mount(bind): umount failed for /tmp/autoeKCAxZ
> > 
> >   instance type(s): file 
> >   map: /etc/auto.home
> > 
> >   * | -rw,intr,vers=3    rhev-01.example.com:/mnt/home/&
> > 
> > 
> > I think it might be related to some deadlock in dumpmaps (bz1527815)
> > 
> > Could you provide fixed version?
> 
> I'll check this out as soon s I can, thanks.

I've managed to build a package with the deadlock fix included
in spite of difficulties with rpcgen availability due to changes
in other packages.

It's revision 5 and I expect it will reach the mirrors in due
course.

In the meantime the build is available at:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1015375

I just wanted to note that this issue does appear (to me) to be fixed.  My rawhide test VMs can properly automount my home directory and the autofs-related dac_override complaints are gone.  (There's still a dac_override denial for gssproxy but it doesn't appear to stop NFS from working, at least, so I'm not complaining.)

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

It's not fixed for us. Our infrastructure in Brno labs is still affected by the issue:

time->Fri Mar 16 13:53:56 2018
type=AVC msg=audit(1521204836.893:102): avc:  denied  { dac_override } for  pid=995 comm="automount" capability=1  scontext=system_u:system_r:automount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=1

selinux-policy-3.14.1-11.fc28.noarch
autofs-5.1.4-12.fc28.x86_

(In reply to Christian Heimes from comment #29)
> It's not fixed for us. Our infrastructure in Brno labs is still affected by
> the issue:
> 
> time->Fri Mar 16 13:53:56 2018
> type=AVC msg=audit(1521204836.893:102): avc:  denied  { dac_override } for 
> pid=995 comm="automount" capability=1 
> scontext=system_u:system_r:automount_t:s0
> tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=1
> 
> selinux-policy-3.14.1-11.fc28.noarch
> autofs-5.1.4-12.fc28.x86_

Can you verify that this is a result of automount not being
able to create the top level mount point directory of the
master map entries.

You can do this by stopping autofs, checking that the top
level directory of the entries in your master map doesn't
exist and then starting autofs.

Then repeat the procedure but create the top level directory
off each of your master map entries before starting autofs.

I suspect this is the problem.

If this is the case, as I have said above, there's nothing
I can do about it within autofs and it isn't acceptable for
autofs to have this selinux restriction.

Ian

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

(In reply to Ian Kent from comment #30)
> (In reply to Christian Heimes from comment #29)
> > It's not fixed for us. Our infrastructure in Brno labs is still affected by
> > the issue:
> > 
> > time->Fri Mar 16 13:53:56 2018
> > type=AVC msg=audit(1521204836.893:102): avc:  denied  { dac_override } for 
> > pid=995 comm="automount" capability=1 
> > scontext=system_u:system_r:automount_t:s0
> > tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=1
> > 
> > selinux-policy-3.14.1-11.fc28.noarch
> > autofs-5.1.4-12.fc28.x86_
> 
> Can you verify that this is a result of automount not being
> able to create the top level mount point directory of the
> master map entries.
> 

sh-4.4# rpm -q selinux-policy
selinux-policy-3.14.1-54.fc28.noarch
sh-4.4# sesearch -A -s automount_t -c capability
allow automount_t automount_t:capability { dac_override dac_read_search net_bind_service setgid setuid sys_admin sys_nice sys_resource };

dac_override allowed in current policy. I assume because lot of other people do not care about additional hardening.

Lets close this BZ

(In reply to Lukas Slebodnik from comment #32)
> (In reply to Ian Kent from comment #30)
> > (In reply to Christian Heimes from comment #29)
> > > It's not fixed for us. Our infrastructure in Brno labs is still affected by
> > > the issue:
> > > 
> > > time->Fri Mar 16 13:53:56 2018
> > > type=AVC msg=audit(1521204836.893:102): avc:  denied  { dac_override } for 
> > > pid=995 comm="automount" capability=1 
> > > scontext=system_u:system_r:automount_t:s0
> > > tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=1
> > > 
> > > selinux-policy-3.14.1-11.fc28.noarch
> > > autofs-5.1.4-12.fc28.x86_
> > 
> > Can you verify that this is a result of automount not being
> > able to create the top level mount point directory of the
> > master map entries.
> > 
> 
> sh-4.4# rpm -q selinux-policy
> selinux-policy-3.14.1-54.fc28.noarch
> sh-4.4# sesearch -A -s automount_t -c capability
> allow automount_t automount_t:capability { dac_override dac_read_search
> net_bind_service setgid setuid sys_admin sys_nice sys_resource };
> 
> dac_override allowed in current policy. I assume because lot of other people
> do not care about additional hardening.

I did do everything I could, and there were a few things to fix, to help
with this but many system administrators that use autofs do expect to be
able to use, possibly a few, directories that don't necessarily exist
initially in the root. And autofs will remove these directories at exit
if they didn't already exist.

The workaround was to manually create the needed directories which will
remain after stopping the service so it only needs to be done once.

> 
> Lets close this BZ

Agreed.

Thanks
Ian

(In reply to Ian Kent from comment #33)
> (In reply to Lukas Slebodnik from comment #32)
> > (In reply to Ian Kent from comment #30)
> > > (In reply to Christian Heimes from comment #29)
> > > > It's not fixed for us. Our infrastructure in Brno labs is still affected by
> > > > the issue:
> > > > 
> > > > time->Fri Mar 16 13:53:56 2018
> > > > type=AVC msg=audit(1521204836.893:102): avc:  denied  { dac_override } for 
> > > > pid=995 comm="automount" capability=1 
> > > > scontext=system_u:system_r:automount_t:s0
> > > > tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=1
> > > > 
> > > > selinux-policy-3.14.1-11.fc28.noarch
> > > > autofs-5.1.4-12.fc28.x86_
> > > 
> > > Can you verify that this is a result of automount not being
> > > able to create the top level mount point directory of the
> > > master map entries.
> > > 
> > 
> > sh-4.4# rpm -q selinux-policy
> > selinux-policy-3.14.1-54.fc28.noarch
> > sh-4.4# sesearch -A -s automount_t -c capability
> > allow automount_t automount_t:capability { dac_override dac_read_search
> > net_bind_service setgid setuid sys_admin sys_nice sys_resource };
> > 
> > dac_override allowed in current policy. I assume because lot of other people
> > do not care about additional hardening.
> 
> I did do everything I could, and there were a few things to fix, to help
> with this but many system administrators that use autofs do expect to be
> able to use, possibly a few, directories that don't necessarily exist
> initially in the root. And autofs will remove these directories at exit
> if they didn't already exist.
> 
> The workaround was to manually create the needed directories which will
> remain after stopping the service so it only needs to be done once.
> 
Not really.

Default configuration of automount reference directories which does not exists.
And therefore it failed to create them. I would expect such directories should be owned by
some rpm if they are in default configuration. (either autofs or fylesystem)

sh# dnf install -y autofs
Fedora Modular 29 - x86_64 - Updates                                       27 kB/s |  22 kB     00:00    
Fedora Modular 29 - x86_64 - Updates                                      1.7 MB/s | 2.3 MB     00:01    
Fedora 29 - x86_64 - Updates                                               28 kB/s |  22 kB     00:00    
Fedora 29 - x86_64 - Updates                                              5.8 MB/s |  26 MB     00:04    
Dependencies resolved.
==========================================================================================================
 Package           Architecture      Version                    Repository                           Size
==========================================================================================================
Installing:
 autofs            x86_64            1:5.1.4-21.fc29            beaker-Fedora-Everything            654 k
Installing dependencies:
 libidn            x86_64            1.35-3.fc29                beaker-Fedora-Everything            231 k
 hesiod            x86_64            3.2.1-14.fc29              updates                              27 k

Transaction Summary
==========================================================================================================
Install  3 Packages

Total download size: 912 k
Installed size: 4.6 M
Downloading Packages:
(1/3): hesiod-3.2.1-14.fc29.x86_64.rpm                                     87 kB/s |  27 kB     00:00    
(2/3): libidn-1.35-3.fc29.x86_64.rpm                                      187 kB/s | 231 kB     00:01    
(3/3): autofs-5.1.4-21.fc29.x86_64.rpm                                    386 kB/s | 654 kB     00:01    
----------------------------------------------------------------------------------------------------------
Total                                                                     390 kB/s | 912 kB     00:02     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                  1/1 
  Installing       : libidn-1.35-3.fc29.x86_64                                                        1/3 
  Installing       : hesiod-3.2.1-14.fc29.x86_64                                                      2/3 
  Running scriptlet: hesiod-3.2.1-14.fc29.x86_64                                                      2/3 
  Installing       : autofs-1:5.1.4-21.fc29.x86_64                                                    3/3 
  Running scriptlet: autofs-1:5.1.4-21.fc29.x86_64                                                    3/3 
  Verifying        : autofs-1:5.1.4-21.fc29.x86_64                                                    1/3 
  Verifying        : libidn-1.35-3.fc29.x86_64                                                        2/3 
  Verifying        : hesiod-3.2.1-14.fc29.x86_64                                                      3/3 

Installed:
  autofs-1:5.1.4-21.fc29.x86_64        libidn-1.35-3.fc29.x86_64        hesiod-3.2.1-14.fc29.x86_64       

Complete!
sh# rpm -V autofs
sh# automount -m | grep "Mount point"
100000000|setautomntent: lookup(sss): setautomntent: No such file or directory
Mount point: /misc
Mount point: /net
sh# ls -ld /misc /net
ls: cannot access '/misc': No such file or directory
ls: cannot access '/net': No such file or directory

But I do not care anymore about it.

(In reply to Lukas Slebodnik from comment #34)
> (In reply to Ian Kent from comment #33)
> > (In reply to Lukas Slebodnik from comment #32)
> > > (In reply to Ian Kent from comment #30)
> > > > (In reply to Christian Heimes from comment #29)
> > > > > It's not fixed for us. Our infrastructure in Brno labs is still affected by
> > > > > the issue:
> > > > > 
> > > > > time->Fri Mar 16 13:53:56 2018
> > > > > type=AVC msg=audit(1521204836.893:102): avc:  denied  { dac_override } for 
> > > > > pid=995 comm="automount" capability=1 
> > > > > scontext=system_u:system_r:automount_t:s0
> > > > > tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=1
> > > > > 
> > > > > selinux-policy-3.14.1-11.fc28.noarch
> > > > > autofs-5.1.4-12.fc28.x86_
> > > > 
> > > > Can you verify that this is a result of automount not being
> > > > able to create the top level mount point directory of the
> > > > master map entries.
> > > > 
> > > 
> > > sh-4.4# rpm -q selinux-policy
> > > selinux-policy-3.14.1-54.fc28.noarch
> > > sh-4.4# sesearch -A -s automount_t -c capability
> > > allow automount_t automount_t:capability { dac_override dac_read_search
> > > net_bind_service setgid setuid sys_admin sys_nice sys_resource };
> > > 
> > > dac_override allowed in current policy. I assume because lot of other people
> > > do not care about additional hardening.
> > 
> > I did do everything I could, and there were a few things to fix, to help
> > with this but many system administrators that use autofs do expect to be
> > able to use, possibly a few, directories that don't necessarily exist
> > initially in the root. And autofs will remove these directories at exit
> > if they didn't already exist.
> > 
> > The workaround was to manually create the needed directories which will
> > remain after stopping the service so it only needs to be done once.
> > 
> Not really.
> 
> Default configuration of automount reference directories which does not
> exists.
> And therefore it failed to create them. I would expect such directories
> should be owned by
> some rpm if they are in default configuration. (either autofs or fylesystem)

Ok, I understand your point but that's not quite the way things are
meant to work with autofs.

The two directories of the default installed master map might be used
but many people that use autofs a lot will use other root directories
that can't be known at install time.

So the daemon does need to be able to create directories.

Also the rpm isn't permitted to create directories in the root without
seeking approval for these directories which doesn't resolve the problem
either.

Possibly it would be worthwhile to seek approval for the /net directory
but /misc is purely an example and the mount targets are unlikely to
work in a normal install.

(In reply to Ian Kent from comment #35)
> (In reply to Lukas Slebodnik from comment #34)
> > (In reply to Ian Kent from comment #33)
> > > (In reply to Lukas Slebodnik from comment #32)
> > > > (In reply to Ian Kent from comment #30)
> > > > > (In reply to Christian Heimes from comment #29)
> > > > > > It's not fixed for us. Our infrastructure in Brno labs is still affected by
> > > > > > the issue:
> > > > > > 
> > > > > > time->Fri Mar 16 13:53:56 2018
> > > > > > type=AVC msg=audit(1521204836.893:102): avc:  denied  { dac_override } for 
> > > > > > pid=995 comm="automount" capability=1 
> > > > > > scontext=system_u:system_r:automount_t:s0
> > > > > > tcontext=system_u:system_r:automount_t:s0 tclass=capability permissive=1
> > > > > > 
> > > > > > selinux-policy-3.14.1-11.fc28.noarch
> > > > > > autofs-5.1.4-12.fc28.x86_
> > > > > 
> > > > > Can you verify that this is a result of automount not being
> > > > > able to create the top level mount point directory of the
> > > > > master map entries.
> > > > > 
> > > > 
> > > > sh-4.4# rpm -q selinux-policy
> > > > selinux-policy-3.14.1-54.fc28.noarch
> > > > sh-4.4# sesearch -A -s automount_t -c capability
> > > > allow automount_t automount_t:capability { dac_override dac_read_search
> > > > net_bind_service setgid setuid sys_admin sys_nice sys_resource };
> > > > 
> > > > dac_override allowed in current policy. I assume because lot of other people
> > > > do not care about additional hardening.
> > > 
> > > I did do everything I could, and there were a few things to fix, to help
> > > with this but many system administrators that use autofs do expect to be
> > > able to use, possibly a few, directories that don't necessarily exist
> > > initially in the root. And autofs will remove these directories at exit
> > > if they didn't already exist.
> > > 
> > > The workaround was to manually create the needed directories which will
> > > remain after stopping the service so it only needs to be done once.
> > > 
> > Not really.
> > 
> > Default configuration of automount reference directories which does not
> > exists.
> > And therefore it failed to create them. I would expect such directories
> > should be owned by
> > some rpm if they are in default configuration. (either autofs or fylesystem)
> 
> Ok, I understand your point but that's not quite the way things are
> meant to work with autofs.
> 
> The two directories of the default installed master map might be used
> but many people that use autofs a lot will use other root directories
> that can't be known at install time.
> 
> So the daemon does need to be able to create directories.
> 

Then can you explain why permissions on / are so strict if autofs
need to be able to create directories there ?

sh# ls -ld /
dr-xr-xr-x. 1 root root 208 Mar 11 15:34 /

sh# ls -ld /opt /mnt
drwxr-xr-x. 1 root root 0 Feb 11 14:47 /mnt
drwxr-xr-x. 1 root root 0 Feb 11 14:47 /opt

sh# rpm -qf / /mnt/ /opt/
filesystem-3.10-1.fc30.x86_64
filesystem-3.10-1.fc30.x86_64
filesystem-3.10-1.fc30.x86_64


I assume because sb did not want to allow create directories in "/".
I have no idea.

> Also the rpm isn't permitted to create directories in the root without
> seeking approval for these directories which doesn't resolve the problem
> either.
> 
> Possibly it would be worthwhile to seek approval for the /net directory
> but /misc is purely an example and the mount targets are unlikely to
> work in a normal install.

Or to use /mnt/net and /mnt/misc in default configuration.
Because /mnt is "Mount point for a temporarily mounted filesystem"
based on [1,2] (and not /)

I know all these changes might break many things if we care about compatibility in enterprise world. 

[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/storage_administration_guide/index#s3-filesystem-mnt

(In reply to Lukas Slebodnik from comment #36)
> > > 
> > > Default configuration of automount reference directories which does not
> > > exists.
> > > And therefore it failed to create them. I would expect such directories
> > > should be owned by
> > > some rpm if they are in default configuration. (either autofs or fylesystem)
> > 
> > Ok, I understand your point but that's not quite the way things are
> > meant to work with autofs.
> > 
> > The two directories of the default installed master map might be used
> > but many people that use autofs a lot will use other root directories
> > that can't be known at install time.
> > 
> > So the daemon does need to be able to create directories.
> > 
> 
> Then can you explain why permissions on / are so strict if autofs
> need to be able to create directories there ?
> 
> sh# ls -ld /
> dr-xr-xr-x. 1 root root 208 Mar 11 15:34 /

I believe that's a policy perhaps originating from someone's interpretation
of the FHS standard and is now being enforced in Fedora.

After doing everything I could to fix problems arising from these changes
this is what was left and is the only thing I have no control over.

The policy change did flush out badness in autofs that needed to be fixed, ;)

> 
> sh# ls -ld /opt /mnt
> drwxr-xr-x. 1 root root 0 Feb 11 14:47 /mnt
> drwxr-xr-x. 1 root root 0 Feb 11 14:47 /opt
> 
> sh# rpm -qf / /mnt/ /opt/
> filesystem-3.10-1.fc30.x86_64
> filesystem-3.10-1.fc30.x86_64
> filesystem-3.10-1.fc30.x86_64
> 
> 
> I assume because sb did not want to allow create directories in "/".
> I have no idea.

Or perhaps because, with selinux (and other security systems) and granular
capabilities, the root user may be able to be made to not have pervasive
permissions.

Maybe working toward that is the goal ...

> 
> > Also the rpm isn't permitted to create directories in the root without
> > seeking approval for these directories which doesn't resolve the problem
> > either.
> > 
> > Possibly it would be worthwhile to seek approval for the /net directory
> > but /misc is purely an example and the mount targets are unlikely to
> > work in a normal install.
> 
> Or to use /mnt/net and /mnt/misc in default configuration.
> Because /mnt is "Mount point for a temporarily mounted filesystem"
> based on [1,2] (and not /)

That's a good idea, it's a short addition to the path, it's a place where
mounts are expected to be and any administrator should check for conflicts
before using it.

Still /net is a common convention that's been widely used by Linux autofs,
amd and autofs on other OS implementations.

So I may be able to make a case for an exception for that, similar to the
exception request for the /afs directory that David Howells has submitted
recently.

Still not sure I'd like to change this upstream though but maybe I'll
come around.

> 
> I know all these changes might break many things if we care about
> compatibility in enterprise world. 

That's also a good point too since autofs usage in Fedora is mostly
not in Enterprise environments.

> 
> [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
> [2]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
> html-single/storage_administration_guide/index#s3-filesystem-mnt

I'll have a read of these and think about what options I may have.

Thanks
Ian