"Null User" - or a way to log out in general

[jondecker76]

The User system badly needs a way to log out. Currently, somebody is always logged in as a user for a particular orbiter. For example, lets say I'm logged in to the on-screen orbiter of my hybrid. I go to work, but at home, my user is still logged in to that orbiter. If I had the hybrid set so that only I could log into it, then my security scheme would fail, as I am the only user that can log in, but yet I can't log out of the orbiter, so while I'm at work my hybrid remains wide open to anybody.

What I am proposing is a "Logout" button on the select user screen. The action of this button would be to take to to a "logged out" screen. This "logged out" screen could, in turn, be the select users screen, with the home button removed and the logout button removed. Then when someone wants to log back in, they just have to touch their name, enter their pin, then they are back to the home screen.

Also, while the above proposal takes care of the "visual" end of things, internally LMCE needs a member varialbe to track the logged out status of each orbiter, set the current user to null, and not allow any orbiter screen except for the "logged out" screen to be shown if it is set.


Anyone agree? Anyone have a better idea of how something like this could be implemented?

[Seer]

Sounds wonderful.  I like the idea.

Should the "null user" be able to do anything?  Power down MD's?  Or might this be accomplished using a "guest" user if one wanted?

[sambuca]

A guest user would be nice for other things too, when you have friends over etc...

But I agree with the basic concept of being able to log out. The guest user could really just be selected using the normal login method.

br,
sambuca

[jondecker76]

good suggestion guys... the "Guest" user could be added behind the scenes...  Now just to figure out what a guest user would be allowed to do.....

[Steve]

I agree 100%

[sambuca]

Yeah, a sensible default for what the guest would be allowed to do would make sense.

Not sure how much access control there is in lmce today. Besides the media files of course.
Maybe just a simple (dis/)allow per scenario, and perhaps a (dis/)allow for advanced also (be able to reload, restart, regen etc.) would be enough?

br,
sambuca

[donpaul]

A winblows style permission would be nice, and maybe a timeout that would log out a user after time/inactivity. The guest account, or "logged out" can only play public media on the MD, use the phone, and arm/disarm the home (with a 4 digit code of course). A restricted user could do everything today's user does EXCEPT reload, regen, delete/move media, power up/down MD, or any other setup/configuration. Then an admin user can do everything. Obviously a new function would need to be added to the user page, to select the type for each user.

Basically I would want my kids to be restricted, and any other bonehead that may use my system. It ws very painful when I went to watch a tv show only to find that my kids had deleted it. They can delete anything in public right now, which is not a good thing. Even my guest account can delete media, change settings, and reload the router.

[ivanp]

Just my 2 cents....
Administrator - all aspects of LMCE
Family member 1 (aka parents) - all non administrative aspects (media (public and private), telecom, alarm, cameras, HA) excluding Webadmin
Family member 2 (aka kids) - media (public and their own), telecom, camera, HA, excluding Webadmin and Alarm (so they dont trigger it accidently)
Guest  (aka any house guest, friend) - media (just public), telecom, camera, excluding HA, Webadmin and Alaram
Null user (default user logged automaticlly after certain period of inactivity of logged user) - media, telecom

I have to say i dont have any LMCE programing expirience but this seems a logical hirerachy to me. Hope it helps

[darrenmason]

I think this thread has evolved somewhat from jondecker's original post and maybe should be split into another one discussing a role based security model (which is effectively what is being suggested).

Back to the original idea which is to have the ability to logout of a an orbiter - I think it is a great Idea and setting the logged in user to NULL or unassigned is probably preferable as it could also equate to logic to determine if an orbiter is actively being used. Additional functionality could logout the user after a specified period of inactivity which would then improve the reliability of 'finding' where users are in the house (this is assuming you are not using mobileorbiter events to track users and their phones)

[donpaul]

I agree, but we should also be able to arm/disarm the house in "logoff mode". There should be a default alarm code that is not tied to a specific user. I think the security system should function more like what people are used to with panel alarms. I myself find it hard to accept the user/alarm function since when my wife is logged in, I have to first select myself, enter pin, then select arm and enter pin again. And my 6 year old who can easily use my panel alarm, has a hard time with the LinuixMCE alarm due to it being tightly tied to the user who is on the orbiter.

[tschak909]

we can add a user selection in the panel, for one possible solution....

But a global PIN is not going to be implemented.

We can make the panel agnostic to the logged in user as well, so that any user's PIN is valid.

It is also worth noting that with mobile orbiters, the right user is always logged in.

-Thom

[donpaul]

We can make the panel agnostic to the logged in user as well, so that any user's PIN is valid.

That seems like the best solution, and provides an interface identical to what people have become used to. A simple change? Hopefully it will be in 8.10 beta.

[tschak909]

yeah, sure. somebody wanna implement it?

It'll take changes to the orbiter's screen handler I believe to do it.

-Thom

[khonshu]

I'm not sure my solution/configuration is the most elegant.  But for a year I have been doing as follows to fit with my network scheme and household members.

My first created user is Administrator, then Guest, then my personal account and other household accounts follow.  I use the same uid scheme on my workstations so NFS derived permissions are consistent, as I use the NFS exports across my network's Linux workstations.  Then I configure my orbiters to select certain users by default.  My common areas, Living Room TV, Dining Room PC, etc, are set to select user Guest by default.  And bedroom orbiters preselected to that user.  Configure your orbiters permissions settings and your there.  The Administrator account, once the other users are configured, I hide from the orbiters, and is only configured for consistency within my network, and to provide the Administrator samba share.

Not important to LinuxMCE, but I follow this same scheme, with uid's startiing at 10000 for my workstations, including Guest at 10001.  This method/configuration I use, has been the same for a year or so, works well, gives me "anonymity" at common orbiters by default, and fits with other common network user schemes.  This also fits with Windows Server 2003 providing Active Directory.  And would fit with this feature request scheme:  http://forum.linuxmce.org/index.php?topic=7839.0

The only thing I could see that you may want to integrate into the default install of LinuxMCE is maybe to configure uid 10000 as Administrator, uid 10001 as Guest, and then ask the user for their household member accounts to follow.  But a individual network plan for your network would suffice.

As I read this threads comments a few more times, I get some further ideas on this subject.  That may alter my user scheme.  I could see use for a "household wide" or global user, that each orbiter is preselected too.  That user could have security mode access.  And a user would not have to be selected to change security mode.  This last thought I have not deployed, as my described configuration has worked for me.  This is interesting to consider options for.  If advanced features, like Samba domain server is to be implemented, a consistant user scheme, with Administrator and Guest accounts will be important.