Bug 1656994

Description of problem:
System is basic F29 with minimal setup. Fedora Workstation. In man systemd-run(1) is following fragment:

       Example 4. Allowing access to the tty

       The following command invokes /bin/bash as a service passing its standard input, output and error to the
       calling TTY.

           # systemd-run -t --send-sighup /bin/bash

If I try to run it either from user account or root I get this issue and it does not actually do anything, just fails with return code 208:

[root@localhost ~]# systemd-run -t --send-sighup /bin/bash 
Running as unit: run-u626.service
Press ^] three times within 1s to disconnect TTY.
[root@localhost ~]# echo $?
208

This is repeatable and I've seen this in other machines.

This module is enough to me to run command without problems:

require {
	type init_t;
	type user_devpts_t;
	class chr_file { open setattr };
}

#============= init_t ==============
# audit(1544124939.426:311):
#  scontext="system_u:system_r:init_t:s0" tcontext="unconfined_u:object_r:user_devpts_t:s0"
#  class="chr_file" perms="open"
#  comm="(bash)" exe="" path=""
#  message="type=AVC msg=audit(1544124939.426:311): avc:  denied  { open } for
#   pid=2447 comm="(bash)" path="/dev/pts/1" dev="devpts" ino=4
#   scontext=system_u:system_r:init_t:s0
#   tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file permissive=0"
# audit(1544125195.683:355):
#  scontext="system_u:system_r:init_t:s0" tcontext="unconfined_u:object_r:user_devpts_t:s0"
#  class="chr_file" perms="open"
#  comm="(bash)" exe="" path=""
#  message="type=AVC msg=audit(1544125195.683:355): avc:  denied  { open } for
#   pid=2619 comm="(bash)" path="/dev/pts/1" dev="devpts" ino=4
#   scontext=system_u:system_r:init_t:s0
#   tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file permissive=0"
allow init_t user_devpts_t:chr_file { open setattr };
SELinux is preventing (bash) from 'open' accesses on the chr_file /dev/pts/1.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that (bash) should be allowed open access on the 1 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c '(bash)' --raw | audit2allow -M my-bash
# semodule -X 300 -i my-bash.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                unconfined_u:object_r:user_devpts_t:s0
Target Objects                /dev/pts/1 [ chr_file ]
Source                        (bash)
Source Path                   (bash)
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.2-42.fc29.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.19.6-300.fc29.x86_64 #1 SMP Sun
                              Dec 2 17:33:14 UTC 2018 x86_64 x86_64
Alert Count                   1
First Seen                    2018-12-06 21:35:39 EET
Last Seen                     2018-12-06 21:35:39 EET
Local ID                      b0b6b561-9b49-4bc4-a78e-6878db84cd0f

Raw Audit Messages
type=AVC msg=audit(1544124939.426:311): avc:  denied  { open } for  pid=2447 comm="(bash)" path="/dev/pts/1" dev="devpts" ino=4 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file permissive=0


Hash: (bash),init_t,user_devpts_t,chr_file,open

Version-Release number of selected component:
selinux-policy-3.14.2-42.fc29.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.9.6
hashmarkername: setroubleshoot
kernel:         4.19.6-300.fc29.x86_64
type:           libreport