You're hitting upon one of the dirty secrets of infosec: MAC and DAC are fundamentally the same thing. They both provide access control, they just have different concepts what a "user", an "administrator", and a "resource" are. There's a reason that MAC didn't become popular until the age of computers administered by people who don't actually use them themselves: on a multi-user mainframe, DAC ACLs set by root look a lot like MAC in practice.
Conversely, take an example of a state-of-the-art "pure" MAC system: Apple's seatbelt profiles, based on BSD's kernel-enforced MAC, are famously used in iOS to prevent even the owner of the device from running anything outside of a sandbox. The real permissions in this case are provided by "entitlements": XML files with a list of perms signed by Apple and included in the binary. In this system, Apple is the MAC admin. No one has a problem calling this MAC, though it looks a lot more like DAC on their own engineering models, where they sign some magic code to let them break the rules.
The real difference between MAC and DAC systems is that MAC systems typically have a more comprehensive notion of the resources to which access is controlled. DAC generally will not prevent you from opening a network socket; MAC might. MAC might prevent IPC; DAC probably won't. Allowed system calls are pretty granular in MAC, not so much under DAC.
Of course, you could get many of the same effects by partitioning programs into individual user accounts and using DAC, because MAC and DAC are fundamentally homomorphic. They just differ in which philosophies they best align with.