Re: [Exist-open] [Exist-development] default perms in collection.xconf do not seem to work

[Chris T. <chr...@gm...>]

Adam,

Thank you for the two emails. I think that will help all of manage expectations and plan for where we are going.

I'm looking at several interim solutions for our immediate needs.

Thanks again,
Chris



On Oct 18, 2011, at 9:17 PM, Adam Retter wrote:

> As for for the Security Roadmap -
> 
> 0) Replace the Configurator with a better design.
> 
> 1) Implement SetUID and SetGID
> 
> 2) Implement Sticky bit.
> 
> 3) Implement ACL permission inheritance
> 
> 4) Move toward full NFSv4 ACL's
> 
> 5) Replace the security manager core with an identified 3rd party library.
> 
> 6) Implement a global Security Session Manager
> 
> 7) Re-work the HTTP and REST security abstractions for consistency
> with the global Session Security Manager.
> 
> Cheers Adam.
> 
> On 18 October 2011 16:29, Adam Retter <ad...@ex...> wrote:
>> Security stuff status -
>> 
>> Basic ACL support is complete.
>> Security permissions checks are now much faster.
>> LDAP support is done, as is Active Directory
>> OpenId and OAuth have also been added.
>> 
>> Security stuff TODO for 1.6 -
>> 
>> 1) Finish migrating from 'rwu' to 'rwx', style permissions, actually I
>> have that done here. But a lot of test cases broke because they were
>> wired around the existing permissions model.
>> 
>> 2) Align the security requirements on operations to the Unix model.
>> That is to say, for example, when you delete a file, the permissions
>> you need to remove a file depend on the permissions of the parent
>> collection and not the file itself. The current model in eXist is
>> somewhat ad-hoc, sometimes it aligns with the Unix model and other
>> times it does not. We need a consistent approach, so we all know what
>> assigning these permissions mean.
>> In fact, im 1/2 way through this, but again the thing that is holding
>> me up is having to fix 100's of tests that have always relied on
>> rather relaxed permissions in eXist-db.
>> 
>> 3) Fix a deadlock issue, this is a design problem with the
>> Configurator. This can be demonstrated through heavy use of the
>> SecuirtyManager. This will be tricky but not impossible, I have an
>> idea for the approach already in mind.
>> 
>> 4) Document the new Security architecture.
>> 
>> All in all this is about 1 weeks work if I can sit down and focus on
>> this for one week solid. My efforts on this are not sponsored and so I
>> have to fit this in amongst work that is sponsored (higher priority).
>> As I mentioned, it looks like I may have a clear week coming up in the
>> near future, and I hope to complete this then.
>> 
>> On 18 October 2011 14:32, Chris Tomlinson <chr...@gm...> wrote:
>>> Adam,
>>> 
>>> It would be a great help if we had a simple roadmap for the security rework. If you can point me to a thread that has the details or hopefully quickly sketch out where we are and where we're going that would be great. I've been following the security stuff and actually thought it had settled down in the early summer and assumed that it was now stabilizing.
>>> 
>>> In fact what what other major items are on the to do list for the next stabilization - 1.6?
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> 
>>> On Oct 18, 2011, at 7:08 PM, Adam Retter wrote:
>>> 
>>>> Yes I have read your emails. I also just responded. I am not deaf to
>>>> the requirement but please do not enable it right at the moment as it
>>>> will impact on outstanding changes I have. As this is all in flux
>>>> before the next release anyway, if you enable it now, it will most
>>>> likely be disabled again later in some way when it is replaced...
>>>> 
>>>> 
>>>> 
>>>> On 18 October 2011 14:12, Wolfgang Meier <wol...@ex...> wrote:
>>>>> Adam,
>>>>> 
>>>>>> Default permissions are no longer configurable, this was a security
>>>>>> design concern.
>>>>> 
>>>>> Have you read our emails? I think there are many arguments why we
>>>>> still need default permissions and I definitely would like to
>>>>> re-enable them.
>>>>> 
>>>>>> New ACL's will permit inheritance in the near future, so this would be
>>>>>> the mechanism for replace such use cases.
>>>>> 
>>>>> ... at least until this mechanism is in place and has been tested.
>>>>> 
>>>>> Wolfgang
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Adam Retter
>>>> 
>>>> eXist Developer
>>>> { United Kingdom }
>>>> ad...@ex...
>>>> irc://irc.freenode.net/existdb
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure contains a
>>>> definitive record of customers, application performance, security
>>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>>> sense of it. Business sense. IT sense. Common sense.
>>>> http://p.sf.net/sfu/splunk-d2d-oct
>>>> _______________________________________________
>>>> Exist-development mailing list
>>>> Exi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/exist-development
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Adam Retter
>> 
>> eXist Developer
>> { United Kingdom }
>> ad...@ex...
>> irc://irc.freenode.net/existdb
>> 
> 
> 
> 
> -- 
> Adam Retter
> 
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb