text: Title: Root inode ACL check is not a strong/safe model
  Body: **Summary**
  Currently, Alluxio has a check on startup that the owner of the root directory in the Alluxio FileSystem matches the user who started the service. This check can lead to breaking scenarios.
  
  Scenario 1: Using HDFS as a UFS
  User runs as superuser of Alluxio filesystem (foo). User (foo) changes permission of / to be owner bar:bar. Command succeeds. In the event of a restart, Alluxio will fail to start since the root inode doesn't match the user who started the process.
  
  Scenario 2: Using HDFS as UFS
  User runs as superuser of Alluxio filesystem (foo). User (foo) tries to change mode of / to be 777. User mistakenly inputs chown instead of chmod. Command succeeds. In the event of a restart, Alluxio will fail to start since the root inode acl (777:foo) doesn't match the user who started the process. Fixing this requires a format.
  
  A better approach may be to skip the root inode ACL check entirely. The original reason for this check is to prevent users from accidentally starting the Alluxio service as the incorrect user. An alternative would be to restrict the journal directory so that the permissions must be 700. If the journal is a kerberized HDFS, the keytab for the HDFS cluster must be restricted to 700 permissions as well. This will prevent any other user from being able to read the journal location configured in alluxio-site.properties and will therefore fail on startup.
  
  **Urgency**
  Can cause breaking scenarios where recovery of the Alluxio process requires creating new user, changing permissions of the Alluxio installation directory, and then starting the service in order to fix the root inode ACL.