Strange was the cgroup file system mounted on /sys/fs/cgroup?

Certainly not by me. Here is the content of /etc/mtab:

/dev/mapper/VolGroup00-LogVol00 / ext4 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw,rootcontext="system_u:object_r:tmpfs_t:s0" 0 0
/dev/sda2 /boot ext4 rw 0 0
/dev/mapper/VolGroup00-LogVol02 /home ext4 rw 0 0
/dev/mapper/VolGroup00-LogVol01 /usr ext4 rw 0 0
tmpfs /tmp tmpfs rw,rootcontext="system_u:object_r:tmp_t:s0" 0 0
tmpfs /var/tmp tmpfs rw,rootcontext="system_u:object_r:tmp_t:s0" 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
capifs /dev/capi capifs rw,mode=0666 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
gvfs-fuse-daemon /home/fedora/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,user=
fedora 0 0

No systemd is supposed to mount it and set it up.

(In reply to comment #0)
> Linux localhost 2.6.36-0.12.rc3.git0.fc15.x86_64

Is it reproducible with the current fc14 kernel too?

Detailed Description:

[SELinux is in permissive mode. This access was not denied.]

SELinux denied access requested by login. /sys/fs/cgroup may be a mislabeled.
/sys/fs/cgroup default SELinux type is cgroup_t, but its current type is tmpfs_t.
Changing this file back to the default type, may fix your problem.

File contexts can be assigned to a file in the following ways.

  * Files created in a directory receive the file context of the parent
    directory by default.
  * The SELinux policy might override the default label inherited from the
    parent directory by specifying a process running in context A which creates
    a file in a directory labeled B will instead create the file with label C.
    An example of this would be the dhcp client running with the dhclient_t type
    and creating a file in the directory /etc. This file would normally receive
    the etc_t type due to parental inheritance but instead the file is labeled
    with the net_conf_t type because the SELinux policy specifies this.
  * Users can change the file context on a file using tools such as chcon, or
    restorecon.

This file could have been mislabeled either by user error, or if an normally
confined application was run under the wrong domain.

However, this might also indicate a bug in SELinux because the file should not
have been labeled with this type.

If you believe this is a bug, please file a bug report against this package.

Allowing Access:

You can restore the default system context to this file by executing the
restorecon command. restorecon '/sys/fs/cgroup', if this file is a directory,
you can recursively restore using restorecon -R '/sys/fs/cgroup'.

Fix Command:

/sbin/restorecon '/sys/fs/cgroup'

Additional Information:

Source Context                system_u:system_r:local_login_t:s0-s0:c0.c1023
Target Context                system_u:object_r:tmpfs_t:s0
Target Objects                /sys/fs/cgroup [ dir ]
Source                        login
Source Path                   /bin/login
Port                          <Unknown>
Host                          banach
Source RPM Packages           util-linux-ng-2.18-4.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.1-2.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Plugin Name                   restorecon
Host Name                     localhost
Platform                      Linux localhost 2.6.35.4-14.fc14.x86_64 #1 SMP Tue
                              Aug 31 21:34:38 UTC 2010 x86_64 x86_64
Alert Count                   10
First Seen                    Wed 01 Sep 2010 05:34:06 PM CEST
Last Seen                     Thu 02 Sep 2010 06:40:46 AM CEST
Local ID                      3d9374aa-d53d-4bd8-8e0b-9b9591672845
Line Numbers                  

Raw Audit Messages            

node=banach type=AVC msg=audit(1283402446.979:74): avc:  denied  { getattr } for  pid=3121 comm="login" path="/sys/fs/cgroup" dev=tmpfs ino=8840 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir

node=banach type=SYSCALL msg=audit(1283402446.979:74): arch=c000003e syscall=6 success=yes exit=0 a0=7f36249205ae a1=7fffeafef600 a2=7fffeafef600 a3=0 items=0 ppid=1 pid=3121 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=5 comm="login" exe="/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)

Note that /sys/fs/cgroup is a tmpfs fs, and /sys/fs/cgroup/systemd is a cgroup fs. A couple of tools verify whether systemd is running by checking whether /sys/fs/cgroup/systemd is mounted, and for that stat() /sys/fs/cgroup/systemd and /sys/fs/cgroup, to compare the block device.

Is it possible that /sys/fs/cgroup/ might need some extra labelling? Should I place "restorecon /sys/fs/cgroup" somewhere? Or shall I add the respective code in C somewhere?

(In reply to comment #6)
The alert returns despite repeated relabeling of /sys/fs/cgroup.

Is this just a functional dup of 627683?

(In reply to comment #7)
> (In reply to comment #6)
> The alert returns despite repeated relabeling of /sys/fs/cgroup.

Note that this is a virtual file system whose contents is lost on reboot, and that includes any labels that might have been applied, if the policy even applies any.


(In reply to comment #8)
> Is this just a functional dup of 627683?

Yes, seems so to me.

Dan, could you comment on my questions from #6? Thanks!

In  selinux-policy-3.9.3-1.fc14  I will label /sys/fs/cgroup
 as cgroup_t which would be the correct label for this.

If systemd is creating /sys/fs/cgroup, it should run the restorecon.

Dan, label_fix() is everything we have to call in the systemd C sources, right? The function is currently used to label the /dev/autofs device properly, and we can just resue it for /sys/fs/cgroup here, right? or do dirs need a different code path here than device nodes?

Oh, and one more question, on top of the ones from comment #11: Should we call label_fix() for the other virtual fs we mount, too?

These are the ones we currently mount:

static const MountPoint mount_table[] = {
        { "proc",     "/proc",                  "proc",     NULL,                MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
        { "sysfs",    "/sys",                   "sysfs",    NULL,                MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
        { "devtmpfs", "/dev",                   "devtmpfs", "mode=755",          MS_NOSUID,                    true },
        { "tmpfs",    "/dev/shm",               "tmpfs",    "mode=1777",         MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
        { "devpts",   "/dev/pts",               "devpts",   NULL,                MS_NOSUID|MS_NOEXEC,          false },
        { "tmpfs",    "/sys/fs/cgroup",         "tmpfs",    "mode=755",          MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
        { "cgroup",   "/sys/fs/cgroup/systemd", "cgroup",   "none,name=systemd", MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
};

Should we call label_fix() on some more of these? Or even all? What about /dev/shm?

No you should only need to call it on files/directories you create.  Not on file systems you mount.  label_fix should work on any of these.

Make that just directories for now.

Hmm, not sure I follow. In comment #10 you said:

"If systemd is creating /sys/fs/cgroup, it should run the restorecon."

In comment #13 you say:

"No you should only need to call it on files/directories you create.  Not on
file systems you mount."

However, /sys/fs/cgroup is a dir that already exists when systemd runs, i.e. is created by the kernel. systemd then only mounts a tmpfs to it.

What should I do now? Call label_fix() before I mount the tmpfs to it, or after?

Ok I think there is something wrong with the way you are mounting cgroups.

grep cgroup  /proc/self/mountinfo  
65 64 0:18 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:15 - tmpfs tmpfs rw,seclabel,mode=755
66 65 0:19 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
67 65 0:20 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,cpuset
68 65 0:21 / /sys/fs/cgroup/ns rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,ns
69 65 0:22 / /sys/fs/cgroup/cpu rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,cpu
70 65 0:23 / /sys/fs/cgroup/cpuacct rw,nosuid,nodev,noexec,relatime shared:20 - cgroup cgroup rw,cpuacct
71 65 0:24 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,memory
72 65 0:25 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:22 - cgroup cgroup rw,devices
73 65 0:26 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:23 - cgroup cgroup rw,freezer
74 65 0:27 / /sys/fs/cgroup/net_cls rw,nosuid,nodev,noexec,relatime shared:24 - cgroup cgroup rw,net_cls
75 65 0:28 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:25 - cgroup cgroup rw,blkio

Why is /sys/fs/cgroup a tmpfs file system?

(In reply to comment #16)
> Ok I think there is something wrong with the way you are mounting cgroups.

What's wrong?

> Why is /sys/fs/cgroup a tmpfs file system?

Because you can place arbitrary mount cgroup hierarchies. Combine controllers, add named hierarchies. 

This is what the /sys/fs/cgroup mount point has been created for: place a tmpfs there and then mount all cgroups hierarchies below it that might be desired, by any name people like.

The problem here is that there is a /bin/mount.tmpfs helper which deals with SELinux labels.  systemd is calling the mount syscall instead of the /bin/mount program which means the helper isn't doing it job which means the labels aren't getting set up correctly.

I'm talking to Lennart on IRC to see what we can do about it....

systemd git now calls label_fix() for all "API" mount points it mounts as part of early initialization.