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

[<jam...@te...>]

> 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.

>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).
> 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 (-;).

Cheers...james