Re: Module removed from user acl hangs around...

[Jamie C. <jca...@we...>]

jam...@te... wrote:

> 
>>That wouldn't really make any difference, unless there was another module
>>also in the /fdisk/ directory, which should never happen. Modules don't
>>
> look
> 
>>at each other's .acl files at the moment, not even for foreign function
>>
> calls
> 
>>(which are always assumed to be trusted).
>>
> 
> Well, what you are really saying is that the webmin infrastructure does not
> support
> this in a portable from release to release way.  To which I would submit
> that if I did
> do a foreign function call, and the thing that I was calling had a ACL
> attached to it,
> I would indeed verify the modules ACL's (which is trivial) to see if the
> current user
> should be doing that.


That doesn't happen, because often one module will make limited use of another
module to carry out certain tasks. For example, a user might have access to the
Change Passwords module but not to Users and Groups. However, the password module
makes foreign calls to users and groups, and edits unix users that the user would
not be able to edit manually. If ACL checking was done at the function level,
this wouldn't be possible ..


>>ACL checking is done at the .cgi program
>>level, not in the underlying libraries,
>>
> 
> Understood from the begining, though that is not a bad idea (-;
> 
> Really, what I am saying is that in a module's .cgi program it decides to
> use
> a foreign function which the .cgi program in the foreign module would make
> some
> ACL check against before calling this foreign-but-not-foreign-to-itself
> function
> then I want to make the same check myself in my module (hope that made
> sense).


That makes sense, and I can see situations in which a module would want
to do that. But none of the core modules have a need to at the moment ..

 
>>so even if you don't have access to the /mount
>>module you can still see information about mounted filesystems in the
>>
> /fdisk module.
> 
> 
>>Anyway, I am totally sure that there is no security risk in leaving .acl
>>
> files around.
> A loose security framework makes it easy for someone who does not fully
> understand the
> framework to oops.  Not to quote a rabbi, but "make fences".
> 
> 
>>If anything, removing them would be a security risk because if you
>>
> deleted a module and
> 
>>then re-installed it, all users with access to it would get fully
>>
> privileges if the .acl
> 
>>files were deleted.
>>
> 
> When you reinstalled the module, no one should have access, because when
> you removed the
> module that module should have been removed from all users list of
> accessible modules.
> Which I assumed was what happened (trying to hope for the best; but then
> again one musn't
> assume (-;).


That doesn't happen at the moment - if you remove a module and then re-install it,
the same people will still have access, with the same permissions. Maybe I should
add an option when removing a module to remove it from all users and to delete all
.acl files ..

  - Jamie