On Wed, Mar 17, 2010 at 11:37, Caleb James DeLisle <calebdelisle(a)lavabit.com
wrote:
>
>
> Denis Gervalle wrote:
> > On Tue, Mar 16, 2010 at 11:08, Caleb James DeLisle <
> calebdelisle(a)lavabit.com
> >
wrote:
> >
> >>
> >> Denis Gervalle wrote:
> >>> On Tue, Mar 16, 2010 at 03:46, Caleb James DeLisle <
> >> calebdelisle(a)lavabit.com
> >>>
wrote:
>
>>>> Right now a script which is saved with programming access is allowed
> to
> >> do
> >>>> things which
> >>>> the viewer (who executes it) is not allowed to do. I would like to
> >> extend
> >>>> this to scripts which do not
> >>>> have programming access.
> >>>>
> >>>> Use case example:
> >>>> A page where the viewer can submit an email address to be put on a
> >> mailing
> >>>> list. The page needs to be able to
> >>>> save the email address to a list but the viewer should not be able
to
> >>>> directly edit (or view) the list.
> >>>>
> >>>> I would like to add to xwiki.api.Context:
> >>>> void setScriptUser(String)
> >>>> String getScriptUser()
> >>>> (These names are the best I could think of, suggestions would be
> great)
> >>>>
> >>>> the input can be either "viewer", "author" or
"default" and it stores
> >> this
> >>>> in the XWikiContext
> >>>> If the value is set to author, hasAccessLevel will return an access
> >> check
> >>>> on the author, not the viewer.
> >>>>
> >>>> When includeForm is called, or the include macro is invoked, the
only
> >>>> explicit change is that changes made by
> >>>> the called document will be reset when the include ends.
> >>>> If scrips are set to run with author's permissions:
> >>>> If DocumentA includes documentB, documentB executes with
documentB's
> >>>> author's permissions.
> >>>> If DocumentA includes _in context_ documentB, documentB executes
with
> >>>> documentA's author's permissions.
> >>>> When include of documentB ends, scriptUser is set back to the value
> >> which
> >>>> documentA left it at.
> >>>>
> >>>> I think this will help us achieve the goal of no documents with
> >> programming
> >>>> rights in the XE xar file.
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Caleb
> >>>>
> >>>> _______________________________________________
> >>>> devs mailing list
> >>>> devs(a)xwiki.org
> >>>>
http://lists.xwiki.org/mailman/listinfo/devs
> >>>>
> >>> First of all, I am personally against adding anything to the
> RightService
> >> in
> >>> its current state. This is already spaghetti code which already lead to
> >> some
> >>> security risks, and trying to improve that partly could be an
> impossible
> >>> challenge. Moreover, this code is absolutely not optimized, you just
> have
> >> to
> >>> put it under debug logging to understand what I mean.
> >> +1 I read it and I know exactly what you mean, I *think* a rights check
> >> could be done
> >> in one query.
> >>
> >
> > I have read it as well, and you may find a document I have written in the
> > drafts of
XWiki.org about how it is currently working. But anyway, look
> at
> > the debug logs even after looking the code, you understand that it even
> > worse than you think.
> >
> >
> >> I was only talking about modifying api.Context and api.Api I have no
> desire
> >> to touch
> >> user.impl.xwiki.ANYTHING!
> >>
> >
> > Isn't this moving some of the RightService responsibility out of it ? I
> am
> > already unhappy with how access are checked, since, these check are not
> only
> > in the right service, but also in many other part of the core, checking
> > special cases, like skin access, inactive user check, etc....
> >
> >
> >>> Regarding the way you expect the inclusion of documents to function, I
> am
> >>> not convince that this is the right choice. The behavior of inclusion
> has
> >>> been broken since Syntax 2.0 has been introduced, and I have always
> feel
> >>> this to be a serious regression. My principal use case is a document
> >> (that
> >>> could have been created by a user) editable by a user, and that store
> >>> objects in itself, and use an inclusion in context for its content. In
> >> this
> >>> case, the user may save the document, which should therefore be without
> >> any
> >>> special rights, but the code may need to have higher privileges, and
> >> still
> >>> require to be included in context for access to the including
> documents.
> >>> This is the typical Sheet case shown in many sample of XWiki
> Programming,
> >>> but with programming right requirement. I have used that many times
> >> before
> >>> it became broken, and this design is still missing to me.
> >> You bring up an important point which I think is worthy of it's own
> email.
> >> I have thought
> >> it would be nice to allow PR code to extend the api or to add velocity
> >> macros
> >> which will run with programming right.
> >
> >
> > This is not exactly what I am saying, I hate the idea that code became
> > broken when an unpriviledged user have just save its container without
> being
> > able to change the code itself. This is currently what happen with
> > inclusion, the user may have no right to change the included document,
> but
> > it break the code by just saving the document that make the inclusion.
> This
> > is what I means when I say that the privilege of a script should be
> tightly
> > linked to who has been able to write it. As a helper mechanism, a script
> may
> > offered the possibility to release its privilege based on the user using
> it,
> > but it could not raise it, since this could lead to major security
> issues,
> > and this release should be the choice of the script author.
> >
> >
> >
> >
> >>> I am convince that the rights given to a block of code should be
> tightly
> >>> linked to the content author
> >> I hereby ammend my proposal to include contentAuthor as a possibility
> for
> >> the set method, I had
> >> forgotten about it.
> >>
> >>> of its containing document, and absolutely not
> >>> based on any author in the context in which it is executed.
> >> Do you mean the viewer? I believe code should never be executed in
> context
> >> of it's viewer
> >> because code may set a trap which saves itself when the viewer has
> greater
> >> privileges than the
> >> code. I propose the set method because I am -1 to changing default
> >> behavior.
> >>
> >>> This has been
> >>> broken in Syntax 2.0, and this currently leads to elevation of
> privilege
> >>> through inclusions. For the same reason, I do not follow Alex on the
> idea
> >>> that the right should be set in place of a user. This would lead to
> many
> >>> problem in regards of who and how this could be set, stored and
> >> inherited.
> >>> I completely agree that the programming right is currently not perfect,
> >> but
> >>> in the same time, I do not see the real value you expect to provide.
> >> There
> >>> is already a similar mechanism in place, using the content author,
> >> opposed
> >>> to the last author of a page.
> >> I want to extend that same mechanism to authors who do not have
> programming
> >> rights,
> >> PR is dangerous and should be used as little as possible and if we need
> it
> >> in the default
> >> xar that is an API flaw IMO.
> >>
> >
> > Making PR more fine grained is for me a task for the RightService not the
> > API.
> > Moreover, extending that without thinking about the whole access policy
> is
> > risky and will create problem for future compatibility.
> >
> >
> >>> This is what make commenting page possible
> >>> without breaking its programming behavior. Extending this to manage
> other
> >>> objects in my use case above, is probably a good track to follow. But
> >> again,
> >>> this should be part of a global reengineering of the RightService.
> >>>
> >>> If you want to rethink the RightService starting from scratch, I will
> >> surely
> >>> participate ! I have already some ideas, but not been able to put them
> >>> properly in a document. Time is always missing, but I hope this to
> >> change...
> >> I absolutely do want to rethink the RightService, however I think it is
> >> held up by the fact
> >> that components have no access to the HttpServletRequest.
> >>
> >
> > I do not agree. Are you sure that you do not confuse authentication and
> > authorization ?
> Yes I suppose I did, so much talk about foaf+ssl and openId, I have been
> thinking
> too much about authentication. Still I think they should both be rewritten
> at once.
>
> > It is still hard to review the authentication part, and this
> > one needs to be extensible and partly depends on the container. For
> > authentication, I really like the modularity of Acegi Security (aka
> Spring
> > Security) model (the model, not the implementation as is), which provide
> a
> > good separation of each roles, allowing easy integration of many way to
> > provide authentications. Authentication should provide a token
> identifying a
> > user and what are the "global" privileges allowed to this token
(group
> > ownership, admin privileges, ???). It should be able to do so for the
> > connected user, and also for a stored token saved with a document (ie the
> > author of a document). It could base its information from many different
> > sources, coming either from the wiki or external to it. It may also
> provide
> > directory services to the wiki.
> >
> > The authorization part is on the other side and should be independent of
> the
> > container or any other external stuffs,
> Here we have the trouble of dependence on the user class, rights class, and
> objects.
> I see this in core java code:
> private static final String USER_CLASS = "XWiki.XWikiUsers";
> as an eye sore and would like to remove it if possible.
> Another alternative is to move that kind of ugliness it out to a
> configuration file.
This should not happen anymore, since for me, users and their privilege and
groups, should be provided by the authentication part. Synchronizing 2
directory is always a pain, so this should be avoided. So I would expect
that a proper authentication module will provide all the answer for the
authorization module, regarding the authenticated user, which means that an
LDAP user will not need to be stored in the XWikiUsers anymore.
and, of
course, the way we
authenticate users. The communication between the two module should be
through some sort of token, that the authentication module ask to the
authorization module when needed. Asking could be for the current
authenticated user, using an existing persisted token or be built
temporarily as a mixed of other tokens for controlling a given script
execution. This second part has to be called anytime a privileged
operation
has to be done on a given object. The caller
should normally not tell
what
he really want to check, but just what operation
he want to do on which
"object". This is the task of the authorization module to know what to
check
and this is precisely why I dislike continuing to
add some sort of "check
this right on this user" anymore.
I guess I don't understand, the way I
see it an authorization check must
check the
permission for entity (user) x to do action y to object z.
I do not fully agree. An authorization check should check that a certain
operation could be executed in the current context on a given entity.
Let say that you want to delete a given document, you need to check that you
can do so now in your execution context, but I really feel that the
conditions to answer your right request should be only the responsibility of
the authorization module. In the non-security code, you should only request
privilege for an operation, and not thinking carefully about what are the
proper conditions for it.
Not that I voluntarily do not talk about users, since I would like to be
able to execute a script in the context of an authentication token having
less privilege than it has at the startup of the script. Tokens are like
keychains for your house. You may have the key, or you may have drop it, it
depends. You may also gain it in some special situation.
Well, this is quick and dirty description of what I feel is needed for
proper and secure right checking, obviously easier to say than to do. But
I
feel the work could be started, especially on the
authorization part,
using
some bridging when require. It will be long, but
I really think that it
is
the price to pay for getting something really
secure.
Long as in a lot of code? I feel that security (and dependability) require
the code
to be short and if it can't be short, isolate the code which runs 90% of
the time
and try to make that short.
Not long code, but short and well formed one should be required. Nice
interface and component will lead to a really better implementation anyhow.
What could be long is the process to agree on the principle and to also
agree on the implementation. This is just ambitious.
Denis
Caleb
Denis
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO