Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of kunklejr@gmail.com designates
 209.85.192.44 as permitted sender)
From: Jeff Kunkle <kunklejr@gmail.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_611DD3D4-6294-4A3A-8777-26DFBC92A501"
Message-Id: <3A4D953C-8AA2-44FF-8FF4-7A00A9D92862@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: "NOT" operator in visibility string
Date: Wed, 19 Mar 2014 11:22:22 -0400
References: <1394052507311-7949.post@n5.nabble.com>
 <CAOyNEs7dj1u+hCGc=sZ-RbmLdid-hTm_weKXCByTrwoNJAy5qA@mail.gmail.com>
 <004301cf3c71$8e2898f0$aa79cad0$@insufficient-light.com>
 <CADczPYTRgVi=3_=7NUv4AkoZ_iA7931YvM_Odfju-ERw6w-dZQ@mail.gmail.com>
 <CAGHyZ6+kNwV7EHjVK=BUk+KLtvW66oJgYu4z=3EQZLqtOMCB3g@mail.gmail.com>
 <CAGUtCHoRW7fEAMrS=eHZA=ZR8+hTmm2Q+rDfed8rU17VTLAevA@mail.gmail.com>
 <CAGHyZ6+-jebtXRm6X9VU_Ei+WkyVhh4T_SKrysKJxhd_m=igkg@mail.gmail.com>
 <531DE9A3.6030502@gmail.com> <1395239784170-8220.post@n5.nabble.com>
 <CAGHyZ6KvtvLvWH4=Nz0qLVz_4ukMx2=XXFv=gk-2vpP1+y1zbw@mail.gmail.com>
To: user@accumulo.apache.org
In-Reply-To: 
 <CAGHyZ6KvtvLvWH4=Nz0qLVz_4ukMx2=XXFv=gk-2vpP1+y1zbw@mail.gmail.com>


--Apple-Mail=_611DD3D4-6294-4A3A-8777-26DFBC92A501
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

My particular use case meets both of those conditions. I=92d like to use =
a not operator to soft delete things for specific groups of users, which =
are assigned a given authorization. For example, assume I have two =
groups of users: group1 and group2. If I want to temporarily hide =
something from group1 I would add =93& !group1=94 to the visibility. In =
my case I=92m not really using the NOT operator for access control. The =
users in the group have access to the data; they=92ve just chosen to =
hide it from their view.=20
=20
On Mar 19, 2014, at 10:47 AM, Sean Busbey <busbey+lists@cloudera.com> =
wrote:

>=20
> On Wed, Mar 19, 2014 at 9:36 AM, kunklejr <kunklejr@gmail.com> wrote:
> So is there any consensus on whether this should be included? I would =
use it
> right away on a current project if it were. I understand the security =
risks
> that have been discussed with having a NOT operator, but I see its use =
as a
> decision to be made by the development team. If the project deems use =
of a
> the NOT operator as too risky, then they should implement a design =
that
> doesn't use it. I don't think you can prevent people from making poor
> decisions/implementations simply by limiting the functionality. It =
could be
> misused as is today.
>=20
>=20
> Could you describe the use case you have in mind? In order for NOT to =
be usable today, you'd need one of two things:
>=20
> 1) Use of visibility labels for something other than enabling access =
control (because you'd have to expressly design for users being trusted =
to only misrepresent themselves appropriately)
>=20
> 2) Client requests would need to pass through an broker application =
that controlled the set of user authorizations and knew not to leave off =
any of the ones used in NOT expressions. This would require a hard =
network boundary between all untrusted clients and Accumulo
>=20
>=20
> -Sean


--Apple-Mail=_611DD3D4-6294-4A3A-8777-26DFBC92A501
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">My =
particular use case meets both of those conditions. I=92d like to use a =
not operator to soft delete things for specific groups of users, which =
are assigned a given authorization. For example, assume I have two =
groups of users: group1 and group2. If I want to temporarily hide =
something from group1 I would add =93&amp; !group1=94 to the visibility. =
In my case I=92m not really using the NOT operator for access control. =
The users in the group have access to the data; they=92ve just chosen to =
hide it from their view.&nbsp;<div>&nbsp;<br><div><div>On Mar 19, 2014, =
at 10:47 AM, Sean Busbey &lt;<a =
href=3D"mailto:busbey+lists@cloudera.com">busbey+lists@cloudera.com</a>&gt=
; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">On Wed, Mar 19, 2014 at 9:36 AM, kunklejr <span =
dir=3D"ltr">&lt;<a href=3D"mailto:kunklejr@gmail.com" =
target=3D"_blank">kunklejr@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">So is there any =
consensus on whether this should be included? I would use it<br>
right away on a current project if it were. I understand the security =
risks<br>
that have been discussed with having a NOT operator, but I see its use =
as a<br>
decision to be made by the development team. If the project deems use of =
a<br>
the NOT operator as too risky, then they should implement a design =
that<br>
doesn't use it. I don't think you can prevent people from making =
poor<br>
decisions/implementations simply by limiting the functionality. It could =
be<br>
misused as is =
today.<br></blockquote><div><br></div><div><br></div><div>Could you =
describe the use case you have in mind? In order for NOT to be usable =
today, you'd need one of two things:</div><div><br></div><div>1) Use of =
visibility labels for something other than enabling access control =
(because you'd have to expressly design for users being trusted to only =
misrepresent themselves appropriately)</div>

<div><br></div><div>2) Client requests would need to pass through an =
broker application that controlled the set of user authorizations and =
knew not to leave off any of the ones used in NOT expressions. This =
would require a hard network boundary between all untrusted clients and =
Accumulo</div>

<div><br></div><div><br></div><div>-Sean</div></div></div></div>
</blockquote></div><br></div></body></html>=

--Apple-Mail=_611DD3D4-6294-4A3A-8777-26DFBC92A501--