> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of José Bollo > Sent: Monday, March 17, 2014 9:48 AM > To: [email protected] > Cc: 전유석; [email protected] > Subject: Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User > Environment > > 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.
Let us be careful about using the term "roles". We do not have a role based system. We do not have the infrastructure to support real "roles". > 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. There should never be a transmute flag on directories with the domain base label. The User label is for domain private data. If you are sharing this with other domains you need to use a different (e.g. User::Shared, User::Applications) label. > 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
