[Shr-Devel] Security features of SHR

[Shaz]

On Fri, May 28, 2010 at 6:00 PM, Carsten Haitzler <raster at rasterman.com> wrote:
> On Fri, 28 May 2010 17:19:53 +0500 Shaz <shazalive at gmail.com> said:
>
>> On Fri, May 28, 2010 at 5:13 PM, Christ van Willegen
>> <cvwillegen at gmail.com> wrote:
>> > On Fri, May 28, 2010 at 2:09 PM, Shaz <shazalive at gmail.com> wrote:
>> >> On Fri, May 28, 2010 at 10:54 AM, Christ van Willegen
>> >> <cvwillegen at gmail.com> wrote:
>> >>> On Fri, May 28, 2010 at 2:06 AM, Carsten Haitzler <raster at rasterman.com>
>> >>> wrote:
>> >>>> On Fri, 28 May 2010 05:00:50 +0500 Shaz <shazalive at gmail.com> said:
>> >>>>
>> >>>>> > For a default "real user", if there's any chance that there may be
>> >>>>> > multiple users on the system, the system should probably just ask,
>> >>>>> > e.g., when getting the initial user password.
>> >>>>>
>> >>>>> We can't expect a smartphone or a mobile or a handheld to have
>> >>>>> multiple users. Can we?
>> >>>>
>> >>>> i'd say you can.
>> >>>
>> >>> /me nods in agreement
>> >>
>> >> Can you guys suggest a usecase?
>> >
>> > My spouse lending my phone, so that she has access to her own
>> > database, messages (and even SIM if we should choose to exchange it).
>> > Lending the phone to another person (that's what PIN2 is for, AFAIK).
>>
>> Still not satisfied because sharing phones is very unusual.
>
> people often enough say: "my phone battery is dead - can i use yours? i'll use
> my sim card so you don't have to pay". and you lend them your phone. you'd like
> the user logged in to be tied to the sim card in this case, so new sim card ==
> create new empty user for it.
>
> another case - corporate use. companies want to make their employees do more
> outside the office - this means being mobile. this also means you have, these
> days, a company phone AND a private phone often enough. the company wants their
> specific apps and customisations isolated on their phones. not mixed up with
> tonnes of other junk/malware/games you install on your private phone. as such
> this separationg is possible via users on a single devce, so in the long term
> when in "work mode" you simply switch to the work user id - it has no access to
> private files, contacts, apps etc. and vice-versa. of course i am assuming 3rd
> party apps are installed in the user homedir as the user id - unless they are
> specific system services.
>
> i can come up with more examples (and yes you could find ways of doing these
> without user id's but as such a privilege separation enforced by a kernel makes
> simple sense here in so many ways, and re-cycles existing concepts unix has
> had for decades that are still useful and applicable).

I like it. And I am satisfied.



-- 
Shaz