On 7.10.2014 14:43, Dominig ar Foll (Intel OTC) wrote:
Proposition from Rafal is far more resistant to potential failure as the addition of user is done under the control of the security manager and the risk unstable state resulting from a failure (such as power lost) is lower.
I don't think it changes anything in terms of reliability. These changes are not transactional operations and at the moment Tizen doesn't use a log-structured file system such as NILFS2 or BTRFS for rootfs, so it can happen no matter how you turn it.
To make it safe you have to use such LFS with specific snapshots before the creation (like Windows is doing for some cases) so that you can roll-back to a know-good state.
What do you intend to do with other subsystems requiring similar interaction? Put more layers on top?
I do agree that the chain should not be long and slow but I disagree on the idea to leave a security related architecture choice to the platform developer. I we encapsulate user creation and removal in the security manager, we shall restrict those call to the security manager.
Tizen is not a product and is distributed as source code. So at best there can be recommendations for system integrator on how to do things. There are no technical means to prevent one from throwing out security manager and SMACK (or gumd for that matter) out altogether.
How someone decides to implement user management GUI is out of my scope... :)
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
