Google has documented both the multi-user feature itself, and the associated API which shows what an application could do with it.
Behind the scenes, the multi-user feature relies on SELinux multi-level (MLS, aka. multi-categories) system where each user is associated to its own SELinux category (see NSA's presentation SELinux in Android Lollilop and Marshmallow for reference, in particular slides 13 and 14). This provides a very robust and reliable separation between users, enforced at Android's kernel level and therefore hardly bypassable.
In this scheme, there are public and private resources. Public resources are shared between all users, while private resources are the own private property of each user and cannot be accessed by others.
- Public resources include mostly installed applications and global phone configuration. Note that you can restrict the way secondary users may use the device, for instance secondary users can be prevented from passing any phone call.
- Private resources include mostly local user's settings, local application and user's data.
Now let's see what are the concrete consequences of these statements (I reuse your convention of user Foo as the primary user and user Bar as the secondary one).
If I create a secondary user and install an app while using the phone
as that user, will the permissions for that app carry over for the
Installed applications are considered as public resources, therefore if the user Bar installs an application then the same application will also be available for user Foo, even if the user Foo did never explicitly accepted the application's requested permissions.
However, user Bar will have no way to make the application run into Foo's profile, neither it will have access to Foo's private data. Moreover, except in the case of a badly buggy or downright malicious application (ie. an application which would copy private data into some shared location), both Foo and Bar can run the application, Foo and Bar's private data will remain safe (they can even use it at the same time if the application supports it, if it does not it will simply refuse to start or crash).
For example, let's say I have a primary user, Foo, with a Google
account email@example.com. I then create the user Bar with the account
firstname.lastname@example.org. Whilst using the phone as Bar, I install an app with
the "find accounts on the device" permission.
Will this allow the app to see the accounts I have registered with the
primary account, i.e. email@example.com?
I just want to warn to not confuse the "Find accounts on the device" permission with the multi-user feature which is unrelated. Each user has its own list of accounts which is considered private information, and therefore not shared to any other device's users.
When Bar runs the application, only Bar's accounts will be available, whereas when Foo runs the application only Foo's accounts will be available.
Will it even be able to find the primary user at all or are there hard
boundaries between user "workspaces" (for lack of a better term), and
as far as the app can see, there's only Bar and its registered
accounts on the device?
The users list seems to be considered as public information, most likely as a Unix world historical inheritance since I do not see any technical reason for this. Personally I would have appreciated if it wasn't the case (ie. users more as transparent sandboxes than standard Unix users, at least as long as applications are not granted some specific permission).
Anyway, the Android API documentation page linked at the beginning of this post lists the methods that an application can use to gather information about current and other users. Most of them do not seem to require any specific permission.
I'm just generally concerned with apps finding out about my personal
data, contacts, emails, etc, and would like to use a "dummy" account
for any app I consider hostile in this regard. Would this work?
Yes, I even think this can be a very good idea, just be sure to be in your dummy account when launching it since the same application may also be available for your primary user.
The multi-user feature in Android systems still seems very young and not very mature. This means that there are impacting changes between Android version and compatibility issues.
- User types and authorization handling: how the primary user and/or a corporate central device administration platform may define or restrict secondary/restricted/profile/guest users rights in terms of functionality and applications they may use or install is subject to heavy changes between Android versions and underlying devices (while still running Android, tablets may offer different options than cellphones).
- The same also applies to the way applications installation, permission requests, applications sharing and uninstallation are processed (they may be directly available, they may be displayed but marked "Not installed for this user", they may not be displayed at all while still leaving the APK available, etc.).
- Some feature may come and go between the broken and fixed state between versions (the "Allow unknown sources" setting for secondary users has been reportedly unavailable for 5.0, fixed in 5.1, broken in 6.0, fixed again in 6.0.1).
- Some applications may not work when using a secondary user (F-Droid for instance).
There are still what I consider to be missing features, for instance there is no proper way for a user to log out.