1.
i would disagree with "only default user is able to install & uninstall
applications". it sounds like an artificial limitation to work around our
installation of apps in system dirs.
i would say "only default user can install/uninstall *SYSTEM* apps
unless they
grant access to other users to do this too" (eg use some group and place
other
users in the same group that allows this - default user is in that group by
default). system apps are available to all users. user installed apps
are only
available to that user. user installed apps of the same name override system
installed apps when executing an app.
2.
the above impacts "all files and dirs owned by root" for apps. this also
nicely
avoids worrying about setuid root binaries in apps... their files are never
owned by root... so who cares? :)
3.
why is there a group id per app? what purpose does this have? it sounds
like a
needless complication (and surely is not sensible if apps are installed as a
user). is this for defining per user access to system apps?
4.
device media storage ... shouldn't this just be spread across /home so all
users already use it? we can use quotas if we want to limit usage per user.
5.
configuration of device i think should be allowed to other users... based on
what the default user decides - eg add user X ro group "wifi" and thus
they can
configure wifi (but not bluetooth, unless added to the "bluetooth"
group). we
don't have to IMPLEMENT the support for adding other users to such groups to
start with, but allow for it in future and ensure we implement the
appropriate
security checks in daemons that configure these things.
6.
developer support should be assignable to any set of users. imagine i have a
small company. i buy 10 phones for my developers to use, but they share
them.
they each have users/logins on these phones, each with their own
config/data/setup, but they all are developers doing development and
they have
10 DIFFERENT phones to test different models and features of hardware and
swap.share them around as needed to save money. same for "developing
application can be launched only as default user and developer user". :)
7.
shell prompt for developer should only support developer user... no. we
NEED to
be able to change user id. we need to be able to switch smack labels. app is
being used as developer, you now suddenly have a bug. it's using 100%
cpu and
you don't know why. normally i'd "ssh in", sudo or su - to the user
logged in
and then strace -p PID. if there is no way to "become" the uid of the given
problem app we are in trouble and can't figure out what's going on. same for
gdb attaching to that problem process etc.
provide a way to do this - it may be sudo + password (set up when developer
mode is set up) or some special setuid root tool that does this auth +
switch,
but it's something we need and developers will demand.
8.
/home/username/dbspace ... please NO! /home/username/.dbspace if
anything ...
hide it by default. and if anything... a db is just config - same thing. it
should just be initted by the app or daemon or lib when/if neeeded. eg
if it's
email maybe /home/username/.config/email/ or for
contacts /home/username/.config/contacts or if its a db for a "facebook
app" .. /home/username/.config/facebook/ - inside these dirs they can do
whatever they like. freedom to put sqlite db;'s or xml files or plain
text or
small furry animals.
9.
per system installed package ... peer user data
(/opt/apps/[pkg_name]/data/[user_name])... sounds .. wrong to me.
On 03/12/2014 10:04 AM, ??? wrote:
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.
Bumjin
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
