On mer, 2014-03-12 at 01:04 +0000, 임범진 wrote: > Hi all, Hi Bumjin, Hi all,
> We have investigated what the security policy should look > like in the multi-user environment considering various > usage scenarios. I believe multi-user support is a > platform wide and full vertical task that everybody should > be involved, so please review the attached proposal and > it'll be happy to hear any feedback. With Dominig Ar Fool, we just finished to exam your proposal. First of all thank you for that proposal that clearly lists the purposes and is a solid foundation to progress. After review, we have a lot of remarks. page 2 ====== Terminology: We prefer to speak about the "main user" ------------ for the user that owns the device and to use the expression "default user" for the unidentified "guest" users. It should be at least one "main user" with the "admin" role, at least one admin: the main user. We disagree with the proposal "most files are owned by root". We want as few root files as possible. We prefer to give system UID to applications. That is the use with UNIX systems: think about users lp, mail, uucp, daemon, man, ntp, sshd, statd, named, dbus, polkit, ..... We disagree with "only default user is able to install & uninstall applications". We prefer to define roles, basically 3 roles: admin, normal, guest. The users with the role of "admin" can add/remove any applications (both user-level applications and system-level applications), (s)he can choose the visibility (all user, some user, non-guest ...). Normal users can install user-level applications for him(her) self only. Guest users can't install or remove application. page 3 ====== Home directory is created when a new user is added, its Smack access label is set to "User" and its smack transmute flag to TRUE. page 4 ====== See above for user roles (admin/user) It is merely a good idea to use 600 as default mask but it is too simple for sharing cases then it must not be strictly enforced. We disagree (see above) with "all files and directories are owned by root". We disagree with "system assign group id per application" and prefer to not make wide use of groups. (typing 'id' currently shows too many groups). page 5 ====== We are okay to launch service not user oriented with their application uid (not a special uid). The user oriented service MUST be launched with the user UID (and also its environment... What may be difficult). page 6 ====== See above (page 3) for putting smack data to user's home directory. User specific data must be created within its home directory by applications and libraries. The best place to use are $HOME/.config/... and $HOME/share/... By principle, daemon should not have specific user data. For the small account of daemons that should have user data (media manager, playlist, ...) we agree that it is the responsibility of the daemon to deal with user add and remove. For external memory cards, we are thinking that the use of links in the home directories is needed for applying quotas (see below page 7). Mounting memory cards would imply the creation/synchronisation of the links and of the data on the card. For example: on the card, should exists the directories: - /home/user1...usern - /opt/... and the main FS would have the links: - /home/user1/sdcard -> /mount/sdcard/home/user1 - /opt/sdcard -> /mount/sdcard/opt That is our draft idea. page 7 ====== Limiting user storage can be made with a quota like mechanism that implies that any user data must be within its home directory. page 8 ====== The users must be able to share their data with others using either DAC (groups or other) or ACL. Then we prefer to not write that file attributes are 600 or 700. page 9 ====== If no user has logged in, it is as if a guest is logged: not an admin. page 11 and 12 ============== We agree that both are out of scope. page 13 ======= The current and common usage is to set the home directory of root to /root not /home/root. We disagree with the use of user ids (names) in subdirectories of /opt. /home is the only place (and sdcards). See https://wiki.tizen.org/wiki/Multi-user_Platform_Metadata and https://wiki.tizen.org/wiki/Multi-user_Architecture for some hints. We disagree with any user specific process at application installation, user add or user remove. By principle, the data have to be created lazily. By principle, deleting the home directory of a user is enough to remove any user data. That point is really important because it improves widely the maintainability and the simplicity. page 14 ======= We agree only with alternative 2 because it doesn't have any {user} dir in /opt. We expect that the links: - /home/user/apps/pkgid/bin -> /opt/... - /home/user/apps/pkgid/res -> /opt/... are only for transitional purpose because it would be better for applications to access there data were they are. We prefer the directory /home/user/.config/appid/.... for application specific data, and the directory /home/user/share/appid for application shared data. Best regards José Bollo > Bumjin > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
