What effect do the user and role labels have on a file in SELinux?

When running ls -dZ /, I get the following output:

system_u:object_r:root_t:s0

Can the user and role fields have any effect access permissions involving a file? Do they mean anything?

TL;DR: Yes, they can have an effect, but on your system, they probably don't.

First some background:

Most Linux distributions shipping SELinux are using a policy based on the so-called reference policy, which contains a functional policy that can be used as a base for site-specific customization, or used as-is.

The attributes you're looking at are: the SELinux user, the role, and the type (or domain) for the file or process. In SELinux, login users are mapped to SELinux users, and then the SELinux users are assigned to roles which they are allowed to perform. Each role has a set of domains that it can transition to. In this way, one can switch a user's role (users can switch their own role with the newrole command, if they are allowed to change roles) to provide or deny access to a completely different set of domains.

In the case of files, access to the file is mediated based on the user and role of the process matching the user and role with which the file is labeled. However, in the case of unconfined users, (and whenever you want, in your own custom policies) these may be ignored and only the type used, or the type ignored as well.

If you're using the default targeted policy, user and role are almost entirely unused, as this policy really does very little with user- or role-based access control, focusing on confining outward-facing services instead. This policy does have some support for confining users, but it is off by default, and all interactive user logins are unconfined.

Under the strict or mls policies, though, user- and role-based access control are much more heavily used. Users are always confined under these policies, and even what the root user can do is limited by placing the root user in the sysadm_r role. Note that the mls policy causes X to break, so you won't generally see it on workstations.

Most SELinux systems you're likely to run across will only be using the targeted policy; it's unusual to find strict or mls in use, though you will see it in places that require the user- and role-based security (e.g. defense contractors). In those cases you'll also likely see that they've customized the users and roles in use.

It's possible to write a complete SELinux policy from scratch, but since this is a lot of work, and carries its own set of nightmares (e.g. documentation or the lack thereof) you won't see it very often. Though if you want to see a demo of role-based access control, this example from IBM of a policy written from scratch serves well.

(A complete answer would be even more theory, so I'll just leave you with this. Day-to-day, the SELinux User Guide is your friend, and for the really tough SELinux questions, the mailing list is also your friend.)