Does not this conflict with the concept of DAC?
 

The fact that chown command requires root privileges? this means the original owner of a file can not transfer the ownership to somebody else? this sounds like MAC?

Sorry for being total noob

it doesn't strictly need root, but it doesn't make sense to allow a user to make a file be opened by someone else of the same security level or higher.

The issues with allowing users to give away files are that it provides a way to evade quotas, or to DoS another user by consuming his quota with a large file somewhere that he cannot delete it or even access it.

1. Copy a shell binary somewhere you have write access to
2. Make it setuid
3. Make it owned by root

Now you can run it and get a shell as root without ever knowing the root password!

This is why limited users cannot run chown. AFAIK this applies to all UNIX and Linux OSes.

Edit: of course you could probably restrict chown to prevent non-root users from setting root ownership, and restrict chmod to prevent non-root users from creating setuid/setgid files. Not sure why this isn't done, maybe it introduces too much complexity and failure-proneness?

(Restricting chmod in particular seems like a good idea to me, limited users should never need to create setuid, setgid, or sticky files/directories. But anyway you can get that effect by mounting all user-writable areas nosuid.)

That's a nice description of why allowing it would be a Bad Thing but it's not the reason why. The actual explanation can be read from 'man capabilities' (CAP_CHOWN) and the description of 'man 2 chown'.

Even in the early days of Unix when users were allowed to chown files, when a non-root user did so the setuid bit was cleared from the permissions. There is a similar protection in place for chgrp and the setgid bit.