Fork me on GitHub

#1 2012-01-22 23:55:46

s0600204
Member
From: UK
Registered: 2012-01-22
Posts: 118
Website

[FIXED] ACL proc:launch restriction vs. eyeX

Right, sorry for the long post. Bear with me!

Starting from the login screen, if there is a session cookie in place on the system, then the various calls to the eyeOS services go something like this...

SERVICE : FUNCTION : PARAMETERS
sec : start
proc : findPidByName : Array (eyeX)
proc : getProcessTable
proc : getTask : Array (79460)
proc : getProcByPid : Array (79460)
proc : getProcessTable
vfs : real_getFileContent : Array (./extern/apps/eyeX/themes/defaultPlus/conf/theme.xml)
...

...however, if there is not a session cookie set, then it looks more like...

SERVICE : FUNCTION : PARAMETERS
sec : start
proc : findPidByName : Array (eyeX)
proc : getProcessTable
proc : launch : Array (eyeX)
proc : getProcessTable
proc : findPid : Array (73405)
proc : getProcessTable
proc : findChecknum : Array (428391541600)
proc : getProcessTable
proc : getTtyByPid : Array ()
vfs : real_getFileContent : Array (./extern/apps/eyeX/themes/defaultPlus/conf/theme.xml)
...

What's the difference?

  • Well, if the first example (with the session cookie set) eyeX is running and so can be accessed straight away via its Pid.

  • In the second example (without a session cookie set) eyeX is NOT running and so has to be launched (by kernal/init.eyecode).

So?
Well, say you were to have an ACL in place that restricts proc:launch and targets 'group'. Then, if you return to the login screen and there is a session cookie, then you get pretty much the first service sequence above. However, if there is not a session cookie in place you get this...

SERVICE : FUNCTION : PARAMETERS
sec : start
proc : findPidByName : Array (eyeX)
proc : getProcessTable
proc : launch : Array (eyeX)
um : getCurrentGroups
*	Curr. User: '' (NULL)
um : retrieveUser : Array ()
vfs : real_getFileContent : Array (./accounts//.xml)
vfs : real_checkPermissions : Array (./accounts//.xml,r)
um : getCurrentUserDir
um : getUserDir : Array (ROOTUSER)
vfs : checkSpecialChars : Array (.xml)
um : getUserFilePath : Array (ROOTUSER)
proc : getProcessTable
proc : findPid : Array (67345)
proc : getProcessTable
proc : findChecknum : Array (965011545631)
proc : getProcessTable
proc : getTtyByPid : Array ()
vfs : real_getFileContent : Array (./extern/apps/eyeX/themes/defaultPlus/conf/theme.xml)
...

So?
Everytime you exit/logout of oneye, the session cookie is removed (as it should be). So everytime you logout the processes occur as described in example 3. Essentially:

  • Page attempts to load

  • kernal/init.eyecode tries to access eyeX via findPidByName

  • it returns false as eyeX is not running, so kernal/init.eyecode launches it instead

  • because there is a restriction on proc:launch, um checks to see if the current user has permission to run it

  • but because it's a login screen, there is no 'current user' - it's null

  • so we get a few functions passing each other null parameters (and having 'false' pass back to them because of the null parameters)

  • and - maybe more pressingly - we also get a

Warning: Invalid argument supplied for foreach() in [EYEROOT]/system/services/um/modules/eyeos.eyecode on line 652

Warning: Invalid argument supplied for foreach() in [EYEROOT]/system/kernel/kernel.eyecode on line 418

So, I can think of three solutions:

  1. First, add a way to override the ACL check in certain circumstances because, frankly, core apps like eyeX and eyeLogin have to run for the system to work, and therefore should be exempt from any check to see if a user can run them. I don't like this as it adds complexity (and we'd need to maintain a list of apps that ACL has no effect on).

  2. Second, set the system so that if it finds that no-one's logged in, it uses a default usergroup instead. (Probably easiest to implement in code)

  3. or Third, find out why eyeX runs automatically without a proc:launch if there is a session cookie set, but needs to be launched by kernal/init.eyecode if there isn't.

And just so I'm clear:

  • Session Cookie Set => eyeX runs automatically, no problem

  • No Session Cookie Set => eyeX is launched by kernal/init.eyecode, resulting in extra service calls, but no real problem

  • Session Cookie Set & ACL rule restricting any group on proc launch => eyeX runs automatically, no problem

  • No Session Cookie Set & ACL rule restricting any group on proc launch => "Warning: Invalid argument..." etc.

So... just out of curiosity... is there a reason eyeX starts itself when there is a session cookie, but has to be launched by kernal/init.eyecode if there isn't?

Last edited by s0600204 (2012-01-23 05:48:28)

Offline

#2 2012-02-03 02:52:16

lucaferrario
Administrator
From: near Como, Italy
Registered: 2011-07-15
Posts: 91

Re: [FIXED] ACL proc:launch restriction vs. eyeX

Very interesting, great analysis!!!
I absolutely agree: we need to improve this mechanism.
But we have to wait for Lars, because he has known the eyeOS architecture since the first versions, so maybe he knows something about this structure which we are ignoring (and I don't want to break the code smile )...
What do you think, Lars?

Offline

#3 2012-03-13 11:29:19

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: [FIXED] ACL proc:launch restriction vs. eyeX

Hey guys,

I just fixed (slightly) our ugly log service and triedout the things from above. But actually I couldn't really figure out what it's about... In eyeOSxxxxxxxxxx/system/kernel/init.eyecode we check if eyeX is already running and get that task in front. In case it does not we launch it. (That's what you see in your first two black boxes.)

Could you try the ACL related example again, please? And do you know if it's possible to deny access to a service function for just everybody and not for a user, group or administrators only?!


Best regards,
Lars Knickrehm

The oneye project.

Offline

#4 2012-03-22 15:28:47

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: [FIXED] ACL proc:launch restriction vs. eyeX

Guys, I need some more feedback on this.

In case none is interested we should tag it as [SKIPPED] or something like that...


Best regards,
Lars Knickrehm

The oneye project.

Offline

#5 2012-03-22 22:59:54

s0600204
Member
From: UK
Registered: 2012-01-22
Posts: 118
Website

Re: [FIXED] ACL proc:launch restriction vs. eyeX

Sorry Lars, I hadn't got round to testing it...

I think the point I may have been trying to make is that if there is no $currentUser set (because no-one's logged in), then there aren't any 'current groups' and as such there's no point wasting processor cycles on trying to find out what they are (from files that don't exist).

Anyhow, the "Warning: Invalid argument..." lines are gone. Thanks.

As far as I know it is NOT possible to deny access to a service function for everybody. You do have to specify a specific user, group or admin. There is, I notice, a DEFAULT_GROUP (stored in system/conf/system.xml), but that's used by eyeControl and the um service to automatically assign newly created users to a predefined group.

And the ACL related example still tries to look for the config files of a null user to check what groups it belongs to. It isn't a fatal problem, just... unnecessary (in my opinion). It could be got round by telling getCurrentGroups to return an empty array if $currentUser is blank, but I leave that up to you. (Alternatively, it could return an array with DEFAULT_GROUP as its only value)

Offline

#6 2012-03-22 23:28:42

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: [FIXED] ACL proc:launch restriction vs. eyeX

Thanks for answering. In order to test this you can use the new log system as described at http://forums.lars-sh.de/viewtopic.php?id=124 wink .

getCurrentGroups  already returns an empty array in that case, cause retrieveUser returns false... Please, check it out when you get some time to. I'll leave this open until you give us some feedback, ok?!

PS: Should we add the possibility to add an ACL for just everybody?


Best regards,
Lars Knickrehm

The oneye project.

Offline

#7 2012-03-23 01:34:56

s0600204
Member
From: UK
Registered: 2012-01-22
Posts: 118
Website

Re: [FIXED] ACL proc:launch restriction vs. eyeX

Actually, getCurrentGroups doesn't return an empty array because retrieveUser does not return false when $currentUser is null. retrieveUser checks to see if its $params variable is set and that it contains at least one value, but it currently fails to check if the value of the contents of $params are null. In short line 165 currently reads

 if($params == null || count($params) < 1) {

A possible solution is to alter line 172 from

if($currentUser != $username && $currentUser != ROOTUSER) {

to

if($currentUser != $username && $currentUser != ROOTUSER || $username == null) {

This causes retrieveUser to return false when $currentUser is false, and does it without an INCORRECT_PARAMS error code being set like at line 166. (As this is going to happen every time someone logs out, setting an error code seems a little pointless)

And I'm not too sure why we'd need an ACL that applies to everyone indiscriminately. The whole point of ACLs is to limit access a specific user or group has to certain functionality. If you have something on, in or part of the system you don't wish anyone to have access to, then why is it part of the system? It's like having a building with a room that absolutely nobody can get into - what's the point of the room? Yes Root is not affected by ACLs so you could, for example, restrict access to an application that needs root access to run, but the application will still show up to normal users and if it truly needs root access to operate then it should refuse to run for anyone else by design anyway. Just my opinion, mind you. Feel free to disagree wink

And the new Log system looks good, although it sure does produce a lot of files!

Offline

#8 2012-03-23 13:26:28

lars-sh
Administrator
From: near Hamburg, Germany
Registered: 2011-07-14
Posts: 731
Website

Re: [FIXED] ACL proc:launch restriction vs. eyeX

I just thought utf8_basename behaves just the way basename does and it did not. I fixed it in revision 7449:

utf8_basename(null) = basename(null) = ''
utf8_basename(false) = basename(false) = ''
utf8_basename(true) = basename(true) = '1'
utf8_basename(array()) = basename(array()) = null

Do you have a nice idea to improve the log service in order to produce less files? Would be good xD ...

About ACL you're absolutely right, but you miss one point: We deliver oneye to a lot independent people and some might like to "disable" functionality for all of their users. E.g. what about disabling access to the calendar through ACL?! I guess that'd be an interesting thing.

I'll commit that feature in some minutes and open a new thread in the forums. Could you add that feature to the new ACL UI, please?

Backlink: http://forums.lars-sh.de/viewtopic.php?id=133


Best regards,
Lars Knickrehm

The oneye project.

Offline

Board footer

Powered by FluxBB