Re: adding ACL enforcement based on ACLProvider, for consistency
I suggest you contact Apache about the issue. Your the first who’s mentioned any problems. For this type of feature request, you’ll need to write the change and send a Pull Request. A Jira issue is vital. Please keep trying and engage Apache if you continue to have trouble. -Jordan > On Apr 21, 2016, at 7:40 PM, Sergey Shelukhin wrote: > > Hi. > For whatever strange reason I cannot choose Apache Curator as the project > when creating a JIRA (I can create in other projects). > So, I figure I¹d post it here. > > Presently, one can supply an ACLProvider when creating CuratorFramework. > That is used to set ACLs when creating directories. > For consistency, it would be nice to have an option to enforce the same > ACLs for the case when the directory already exists. > > In a secure scenario, one could assume that the ACLs on his secure nodes > would be set to whatever ACLProvider dictates; however, if someone has > created the node before with a different ACL (say, giving themselves > access), this assumption would be broken. As of now, the ACLs need to be > verified or enforced manually. > >
Re: adding ACL enforcement based on ACLProvider, for consistency
Not sure if this is related but a bunch of projects in the Apache JIRA got hit with a strange series of Spam messages in newly created JIRA tickets yesterday. I know Infra adjusted some of the permissions for users as a result. On Fri, Apr 22, 2016 at 10:48 AM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > I suggest you contact Apache about the issue. Your the first who’s > mentioned any problems. For this type of feature request, you’ll need to > write the change and send a Pull Request. A Jira issue is vital. Please > keep trying and engage Apache if you continue to have trouble. > > -Jordan > > > On Apr 21, 2016, at 7:40 PM, Sergey Shelukhin > wrote: > > > > Hi. > > For whatever strange reason I cannot choose Apache Curator as the project > > when creating a JIRA (I can create in other projects). > > So, I figure I¹d post it here. > > > > Presently, one can supply an ACLProvider when creating CuratorFramework. > > That is used to set ACLs when creating directories. > > For consistency, it would be nice to have an option to enforce the same > > ACLs for the case when the directory already exists. > > > > In a secure scenario, one could assume that the ACLs on his secure nodes > > would be set to whatever ACLProvider dictates; however, if someone has > > created the node before with a different ACL (say, giving themselves > > access), this assumption would be broken. As of now, the ACLs need to be > > verified or enforced manually. > > > > > >
Re: adding ACL enforcement based on ACLProvider, for consistency
I just saw this on the Apache Jira: "Jira is in Temporary Lockdown mode as a spam countermeasure. Only logged-in users with active roles (committer, contributor, PMC, etc.) will be able to create issues or comments during this time. Lockdown period from 22 April UTC to estimated 22 April 2000 UTC.” So, wait until the lockdown is over. > On Apr 22, 2016, at 9:48 AM, Jordan Zimmerman > wrote: > > I suggest you contact Apache about the issue. Your the first who’s mentioned > any problems. For this type of feature request, you’ll need to write the > change and send a Pull Request. A Jira issue is vital. Please keep trying and > engage Apache if you continue to have trouble. > > -Jordan > >> On Apr 21, 2016, at 7:40 PM, Sergey Shelukhin wrote: >> >> Hi. >> For whatever strange reason I cannot choose Apache Curator as the project >> when creating a JIRA (I can create in other projects). >> So, I figure I¹d post it here. >> >> Presently, one can supply an ACLProvider when creating CuratorFramework. >> That is used to set ACLs when creating directories. >> For consistency, it would be nice to have an option to enforce the same >> ACLs for the case when the directory already exists. >> >> In a secure scenario, one could assume that the ACLs on his secure nodes >> would be set to whatever ACLProvider dictates; however, if someone has >> created the node before with a different ACL (say, giving themselves >> access), this assumption would be broken. As of now, the ACLs need to be >> verified or enforced manually. >> >> >
Re: adding ACL enforcement based on ACLProvider, for consistency
Appears some projects are still being hit as of 11:45am. On Fri, Apr 22, 2016 at 11:53 AM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > I just saw this on the Apache Jira: > > "Jira is in Temporary Lockdown mode as a spam countermeasure. Only > logged-in users with active roles (committer, contributor, PMC, etc.) will > be able to create issues or comments during this time. Lockdown period from > 22 April UTC to estimated 22 April 2000 UTC.” > > So, wait until the lockdown is over. > > > On Apr 22, 2016, at 9:48 AM, Jordan Zimmerman < > jor...@jordanzimmerman.com> wrote: > > > > I suggest you contact Apache about the issue. Your the first who’s > mentioned any problems. For this type of feature request, you’ll need to > write the change and send a Pull Request. A Jira issue is vital. Please > keep trying and engage Apache if you continue to have trouble. > > > > -Jordan > > > >> On Apr 21, 2016, at 7:40 PM, Sergey Shelukhin > wrote: > >> > >> Hi. > >> For whatever strange reason I cannot choose Apache Curator as the > project > >> when creating a JIRA (I can create in other projects). > >> So, I figure I¹d post it here. > >> > >> Presently, one can supply an ACLProvider when creating CuratorFramework. > >> That is used to set ACLs when creating directories. > >> For consistency, it would be nice to have an option to enforce the same > >> ACLs for the case when the directory already exists. > >> > >> In a secure scenario, one could assume that the ACLs on his secure nodes > >> would be set to whatever ACLProvider dictates; however, if someone has > >> created the node before with a different ACL (say, giving themselves > >> access), this assumption would be broken. As of now, the ACLs need to be > >> verified or enforced manually. > >> > >> > > > >