RAM is first-come-first-serve. If userA runs 9 processes that allocate 10% of memory each, and then userB logs on, userB will see only 10% of memory left. In the event that memory is exhausted, Linux will start killing processes. The OOM killer is not tuned for multi-user, as far as I know, so it may be unfair in this scenario.
CPU time is generally allocated on a per-process basis, not per-user (but see below).
Any process which is ready to run (not sleeping, waiting on I/O, etc.) is considered for scheduling. (Processes which are not ready to run, are ignored, and so "don't count". (This is a slight oversimplification, but close enough.))
In the simplest model, if two users are running one process each, they each get roughly half of available CPU time. But if userA is running 10 processes, and userB is running 1 process, then userA gets 90% of CPU and userB gets 10% of CPU (all other things being equal).
However, the Linux scheduler can refine this by grouping processes together, and then allocating CPU time between those groupings.
Further, Linux has the capability to automatically group processes based on the session ID (typically associated with terminals, terminal windows, and/or X login sessions). This is called "autogrouping". The goal is that a single user running a heavy background task in one window, and an interactive task in another window, will still see responsive interactive performance.
Both of these capabilities are enabled by default on Ubuntu, as far as I can determine.
I cannot find information on how task groups and/or autogrouping behave in a multi-user workload. In theory, if the scheduler put each user in a separate task group, then users would always get balanced access to the CPU (50/50 for two users). However, I don't find anything that says this will happen automatically.