►
From YouTube: Kubernetes Data Protection WG Bi-Weekly Meeting 20211215
Description
Kubernetes Data Protection WG Bi-Weekly Meeting - 15 December 2021
Meeting Notes/Agenda: -
Find out more about the K8s DP WG here: https://github.com/kubernetes/community/tree/master/wg-data-protection
Moderator: Xing Yang (VMware)
A
A
Today
we
have
one
main
thing
on
agenda:
rona
is
going
to
talk
about
his
proposal
on
voting
mode
conversion
again
addressing
the
feedback
that
he
got
from
the
previous
meeting.
A
B
Hey
attention
hi
everyone.
Let
me
just
share
my
screen
and
we
can
get
started.
B
Hey,
hey
sorry,.
C
Yeah
perfect,
so
hey
everybody.
Let
me
just
start
off
with
some
background
about
the
problem
and
then
I'll
sort
of
speak
about
what
feedback
we
got
from
from
the
last
meeting
and
then
some
sort
of
solutions
that
we've
sort
of
come
up
with
the
reasons
fast
and
then,
of
course,
it's
always
open
to
discussion.
C
So
the
main
issue
that
we
have
is
that
currently
we
don't
have
any
logic
at
the
kubernetes
layer
which
validates
whether
the
volume
mode
of
a
pvc
which
is
being
restored
from
a
snapshot
matches
the
volume
mode
of
the
snapshot
that
was
taken.
C
So
what
I
mean
is
a
user
can
currently
create
a
pvc
with
the
volume
mode
of
block
and
then
do
a
bunch
of
stuff
to
like.
You
know,
write
malform
data
to
it,
take
a
snapshot
of
this
volume
and
then
restore
the
volume
with
sorry
restore
the
snapshot
into
a
pvc
with
the
volume
mode
of
file
system.
C
So
currently
there
is
no
like
sort
of
cve
or
whatever
that
that
that
is
that
makes
the
system
vulnerable
to
this
sort
of
issue.
But
we
do
want
to
sort
of
prevent
any
future
cve
from
exposing
this
vulnerability
right
and
the
reason
we
can't
just
block
this
particular
operation
is
that
there
are
backup
vendors,
which
sort
of
actually
use
this
process
this
this
process
of
restoring
or
of
restoring
with
the
change
in
the
volume
mode.
C
They
actually
use
that
legitimately
to
do
the
backups
to
do
their
backups
more
efficiently.
So
it's
sort
of
a
valid
use
case
in
some
cases,
but
an
invalid
use
case
in
most
cases.
So
can
you
just
scroll
down.
A
C
A
But
I
absolutely
okay
so
like
this
high
level
diagram,
so
I
remember
fong
has
a
diagram
that
talks
about
this
right.
Do
you
do
you
found?
I
thought
you
have
some
some
diagram
talking
about.
A
Okay,
I
thought
you
have
some
diagram.
Maybe
we
can
just
draw
something
similar.
I
I
do
not
have
it.
E
On
top
of
my
I
I
I
I
I.
E
I
remember
you
have
something
right:
yeah
we
did
an
experiment
where,
in
which
we
create
the.
A
E
In
the
in
the
back
end,
sorry,
it's
a
it's
a
it's
a
block
storage,
but
when
we
export
it
to
the
kubernetes,
it
is
a
file
mode
in
the
file
system
mode.
So
when
we
do
backup
in
the
in
the
back
end,
we
do
it
in
like
a
block
mode.
So
there
might
be
some
conversion
back
and
forth
so
that
it
would.
If
you
want
to
do
like
a
different
show
snapshot,
it
will
be
more
efficient
to
do
it
in
using
the
blog
board,
and
that
is
the
whole.
E
You
know
generic
idea
behind
that
most
transferring
back
and
forth
between.
You
know
when
we
do
a
backup
and
when
we
restore
it
and
so
on
and
so
forth,
to
make
it
efficient
using
the
backup
that
you
saw
for
different
snapshots
for
the
full
volume
snapshot.
This
makes
no
difference.
So
that
is
just
some
background
behind
the
logic.
A
Okay,
so
there's
another
question
from
her.
Basically
is,
I
think
we
we
don't
really
have
capabilities
for
this?
Oh
actually,
we
actually
we
do
right.
We
do
have
the
capabilities
to
say
whether
you
do
so
so
like
the
in
your
in
your
backup
software.
Do
you
actually
check?
A
So
you
know
that
is
the
block.
Can
you
make
this
conversion
or
not
before
you
are
doing
this?
I
guess
how
do
you
make
the
decision?
Because
if
it's
a
file
is
a
file
share
right
with
the
file
system,
then,
if
I
warn,
then
you
cannot
really
do
this
conversion.
Do
you
do
you
have
to
do
some
check
before
before
that?
How
do
you
make
the
decision?
I
guess
that's
the
question.
E
I
don't
remember
the
particular
chats
that
we
do.
I
think
we.
A
E
In
the
experimental
phase,
at
that
point
yeah
we
only
try
to
experiment
what
workflow
is
possible
if
we
want
to
do
it
back
up
more
efficient
and.
F
E
Is
the
story
behind
that
when
we
go
to
the
implementation
phase,
we
we
will.
You
know,
check
more
on
the
on
on
that
type
of
thing.
A
Okay,
so
how
do
you
do
you,
support
file
volumes
already
or
that's
like
the
future.
E
For
for
the
pvc,
yet
we
only
have
the
five
volume
on
this
and
or
pvc.
A
A
A
A
G
A
Matter,
I'm
sorry,
you're
saying,
doesn't
matter
whether
it's
a
read
only
or
what
what
do
you
say.
D
A
Oh
restore
basically,
that's
actually,
if
you
read
this
one
right,
so
it's
actually
you're
actually
creating
a
volume
right.
So
then
the
the
pod
tries
the
crash
happens
when
cubicles
try
to
mount
it.
A
I
G
Crashing
the
the
the
specific
security
thread
is:
if
you
write
a
malformed
file
system
into
a
block
volume,
and
then
you
convert
it
back
to
a
file
system
volume
by
snapshotting
it,
including
the
snapshot
when
the
kernel
tries
to
perform
the
mount
on
the
malformed
file
system,
you
can
exploit
security
vulnerabilities
in
the
kernel
either
by
crashing
the
kernel
or
taking
it
over.
You
know:
there's
various
theoretical
security
problems.
H
No,
it's
not
these
people
they
can.
They
can
bypass
fck
fsck.
F
Well,
I
think,
there's
two
different
things
so
straight
up
crashing
fsdk
should
fix.
Unless
you
know
I
mean
because,
basically
anything
you
could
do
by
hand
you
could
get
by
random.
You
know
just
random
corruption
right
right.
G
F
G
H
If
fsck,
if
you
ever,
even
if
you
do
fsck,
there
were
some
cves
where
fsc
fsck
was
okay
and
you
can
still
crash
the
kernel.
A
Well,
anyway,
we're
talking
about
this
is
a
potential.
So
I
don't
think
we
you
know,
because
we
don't
really
have
like
a
real
case,
that
we
want
to
prove
here,
but
we
want
to
avoid
this
from
happening.
If
if-
and
there
is
any
possibility
right.
So
that's
why
this
is
like
not
like
a
high
priority
thing,
but
we
still
want
to
fix
it
because
we
do
do
this
month
right.
So
that's
a
pretty
high
privilege.
B
A
G
A
Actually,
there
are
lots
of
use
cases
for
that.
One,
though,
is
this:
the
wait
for
first
consumer
thing,
that's
actually
also
optional
right.
That's
not
like
is
that
the
required,
because
I
well,
I
actually
tried
your
public
code.
I
see
the
the
pvp
before
the
part
is
created,
so
you
still
have
it's
like
you
support
both
right.
It's
not
like
it
has
to
be
way
for
first
consumer,
correct.
A
All
right,
yeah,
probably
that's-
maybe
let's
get
back
to
this
one.
C
C
Yeah,
so
let
me
just
speak
briefly
about
the
changes
to
the
volume
snapshot
content
api.
As
part
of
this,
like
proposal,
I'm
gonna.
C
The
next
okay,
okay,
so
so,
basically,
there
are
a
couple
of
changes
in
the
snapshot:
content
api,
as
well
as
a
snapshot
controller,
because
currently
there's
no
like
communication
of
the
volume
mode
between
pvc
snapshot
or
snapshot
to
pvc.
So
the
basic
idea
is
that
we
would
add
this
the
source
volume
mode
to
the
snapshot,
content
structure,
which
is
basically
added
sorry.
So
it's
added
to
the
spec
and
then
it's
using
if
you
can
just
scroll
down
a
little.
C
Thank
you
so
so,
then,
the
snapshot
controller
is
going
to
create
the
snapshot
content
right
so
when
it
creates
the
snapshot
content,
it's
going
to
populate
the
spec
of
that
snapshot,
content
with
the
volume
mode
of
the
persistent
volume
and
I've
actually
given
just
a
bunch
of
references
we're
currently
in
the
code.
This
snapshot
controller
actually
has
access
to
this
information.
It
just
doesn't
do
anything
with
it
and
these
changes
before
I
move
on
any
questions.
I
think
we
spoke
about
this
last
time
as
well.
C
Right,
so
these
changes
are
actually
going
to
help
us
with
with
preventing
like
illegitimate,
changing
of
the
volume
mode
and
last
time
we
actually
spoke
of
two
sort
of
potential
proposals
to
how
we
should
handle
it.
C
We,
so
basically
the
idea
was:
do
we
introduce
a
new
crd
with
you
know,
a
bunch
of
users
which
would
be
allowed
to
sort
of
change
the
volume
mode
or
do
we
do
also
introduce
a
new
verb,
which
is
something
I
think
someone
brought
up
where
you
can
actually
add
a
new
verb
and
then
sort
of
modify
the
r
back
of
a
given
user
and
stuff
like
that,
so
I
haven't
I,
I
guess
I
haven't
gone
to
a
lot
of
detail
in
terms
of
what
the
exact
implementation
would
be
in
this
table,
but
my
idea
is
just
to
sort
of
have
a
side-by-side
comparison
and
then
you
know
just
discuss
the
pros
and
cons
of
either
approach.
C
So,
starting
with
you
know,
just
a
new
crd
again,
the
games
and
stuff
are
just
you
know
not
really
thought
through.
So
don't
give
that
too
much.
Don't
think
into
that
too
much.
But
the
idea
is
that,
basically,
we
introduce
a
new
crd
where
the
spec
contains
a
bunch
of
users.
C
Now
the
users
can
be
individual
users
or,
I
guess
even
service
accounts,
and
the
idea
is
that
the
admin
is
going
to
create
or
modify
this
crd
with
the
bunch
of
users
that
are
allowed
to
change
the
volume
mode.
C
So
in
this
case,
if
the
admin
knows
that
you
know
there's
a
backup
vendor
and
they
have
this,
this
they're
using
this,
the
service
account-
or
this
particular
user
they'll-
add
that
to
crd
and
we'll
also
sort
of
introduce
an
admission
controller
as
part
of
this
implementation,
which
is
going
to
intercept,
requests
to
create
pvcs
and
basically,
when
a
request
comes
in
to
create
a
pvc,
this
admission
controller
is
gonna
sort
of
compare
the
volume
mode
of
the
of
the
snapshot.
C
I
mean,
first
of
all,
it's
going
to
evaluate
whether
that
pvc
is
being
restored
from
a
snapshot.
If
yes,
then
go
ahead
and
compare
the
volume
mode
of
the
two.
As
we
spoke
about
just
a
few
minutes
ago,
this
volume
mode
is
now
present
in
the
snapshot
content
as
well,
and
if
they
don't
match,
then
the
admission
controller
basically
reads
this
new
crd
and
validates
whether
the
requesting
user
is
present
in
the
list
of
so-called
allowed
users.
C
C
No,
so,
actually,
last
time
we
spoke
about
an
annotation,
adding
an
annotation
to.
A
C
A
C
And
I
think
ben
brought
up
this
issue
of
mutability
right,
what
if
the
user
is
added
or
removed
or
whatever
right.
A
A
Does
this
one
allow,
so
this
one
can
be
updated,
basically,
is
that
the
sync
right.
A
C
Every
request
to
create
a
pvc
is
going
to
go
and
look
at
this
list
so
yeah
it's
immutable
in
that
way.
A
I
think
there
are,
but
I
need
I
need
and
you
find
out,
I
believe
I've
seen
some
somewhere,
but
I
couldn't
remember
exactly
what
that
is
right.
Now,
yeah.
I
G
Sure
yeah
go
ahead,
go
ahead.
Well,
I
was
just
gonna
say
I
think
the
argument
is
any
system
that
piggybacks
on
the
rbac
system
gets
to
take
advantage
of
all
the
weird
tricks
you
can
play
with
rbac,
where
you
can
have
like
a
user
impersonating,
another
user
or
user
with
a
you
know,
with
the
scoped
token,
that
has
a
subset
of
what
a
user
can
do
like
there's
all
sorts
of
magic
inside
the
rbx
system,
and
if
you
step
outside
of
it
and
just
say
well,
this
user
can
do
this.
G
I
F
A
The
problem
with
this
one-
I
I
see
potential
well,
I
I
look
at
this
one
see
this
one
looks
very
similar
to
what
we
were
trying
to
propose
earlier.
Is
this
it's
exactly
the
name
volume
security
policy.
We
were
looking
at
this
earlier.
It
got
rejected
because
we
want
to
follow
the
you
know.
This
is
like
pod
security
policy,
so
we
want
to
follow
apart
security
standard,
but
then
part
security
standard
got
rejected
by
seek
off
because
that's
too
complicated
yeah.
So
that's
why.
A
This
approach,
I
think
it's
just-
we
have
the
same
issue-
that
the
reason
that
we
got
rejected
by
going
to
the
new
security
standard
thing,
which
is
actually
should
be
a
replacement
of
this
one.
The
comment
we're
getting
from
jordan
is
that
you
are
trying
to
solve
a
tiny
little
small
use
case,
but
you
are
trying
to
come
up
with
a
very
complicated
approach.
A
It's
really
not
necessary,
so
yeah,
so
I
think
I'm
looking
at
this
one.
We
are
actually
looking
at
the
the
open
shift.
The
document
I
mean,
I
think
it's
good
to
to
add
that,
but
then
we
have
to
come
up
with
the
tons
of
use
cases
right
now.
We
do
not
that's
the
problem,
we're
trying
to
solve
this
one
problem,
and
then
we
are
coming
up
with
a
very
comprehensive
approach
that
can
solve
like
hundreds
of
problems,
which
is
not
a
approval.
G
A
Then
you
have
to
come
up
with
you
have
to
when
we
have
to
first
imagine
some
cases
right.
You
guys
can
help
with
the
list
give
us
a
list
of
yeah.
We
can
actually
do
it
right
now.
Why
don't
you
guys
help?
Maybe
you
can
think
about
like
what
are
the
things
that
we
want
so
right
now
this
is
one
use
case.
A
Issues,
you
know
go
waste
time
on
things
like
that's
already
rejected
right.
So
if
we
really
think
we
have
a
better
reason
to
say,
hey
we
have
to
go
go
back
to
then
we
go
back
to
the
this
other
thing.
The
security
standard.
F
I
To
what
we're
proposing
has
been
rejected,
but
I
think
that
the
current
proposal
that
we're
asked
that
the
that
is
the
alternative
to
the
one
that
has
been
previously
rejected,
I
think,
has
some
some
problems
that
we
would
have
to
address.
Yeah.
A
I
I
That
makes
sense,
but
then
can
you
help
us
brainstorm?
How
you
would,
instead
of
using
a
list
of
users,
use
the
entire
r
back,
like
authorization
scope
of
of
a
user,
to
compare
in
that
situation,
because
if
we're
gonna
say
that,
like
the
other
one
is
the
one
that
you
think
we
should
do
that
we
should
do.
Then
can
we
brainstorm
on
that?
Then.
G
G
A
G
At
the
moment,
I'm
sorry
about
that
real,
quick
I'll,
try
one
more
time
and
then
give
up.
If
you
want
to
maintain
the
property,
you
can
change
the
policy
after
the
fact,
in
terms
of
like
adding.
A
G
I
But
I
think
what
he
said
was
that
if
you
wanted
a
pro
the
property
that
you
could
add
new
users
to
use
the
existing
one
after
it
was
created
and
you
wanted
the
he
just
had
another
thing,
I'm
sorry,
but
I
think
there
was
another
property
that
he
also
said.
I
think
he.
E
C
I
A
A
This
is
actually
also
having
you.
I
think
the
title
is
not
it's
a
misleading,
actually
both
introduce
new
crds,
it's
just
the
the
left.
One
is
narrower.
It's
just
focusing
on
this
one
use
case
the
one
on
the
right
hand
right
hand
side.
Basically,
it
was
trying
to
handle
more
a
lot
more
use
cases
this,
because
the
one
and
left
hand
side
also
introduce
new
verbs
and
new
crds.
A
A
Okay
you're
saying
oh
you're
saying
this:
this
is
the
use
verb
exactly
yeah.
B
A
Yeah,
I
guess
that's
the
thing
that
I'm
not
seeing
that
that
is
absolutely
necessary.
C
C
A
And
not,
and
one
thing
I
want
to
do
anyone
here,
familiar
with
the
redheads,
this
security
context
thing
and
maybe
young's
familiar
with
that.
How
is
that
different?
From
the
you
know,
the
pod
security
policy.
A
A
The
pattern
is
dedicated,
the
whole
thing
is
deprecated.
We
should.
If
we
look
at
that
one,
we
should
actually
look
at
the
part
secret
standard.
We,
if
we
look
at
that
one
we
want
to
say,
can
we
do
this?
Then
we
actually
should
look
at
a
volume
security
standard
which,
which
was
something
that
we
looked
at
earlier.
That's
what
I'm
saying.
A
A
But
at
least
for
upstream
right
right,
let's
say
purely
supposedly,
you
would
support
a
pure
kubernetes
distro
as
well
right.
So
whatever.
F
A
By
pod
security
standard,
then
you
will
have
to
support
that
at
least
correct.
I
think
so.
Okay
yeah,
I
just
said
we
will
still
have.
H
A
A
C
H
Yeah,
I
have
a
very
different
question.
So
can
we
just
do
we
know
at
the
admission
time
if
the
security,
now
it's
bought,
damn.
A
I
was
actually
wondering
not
at
this
point
I
I'm
thinking.
Maybe
I
think
we
probably
need
to
do
some
prototyping,
instead
of
just
going
through
the
series
that
may
help
actually.
K
A
Because
there
are,
some
part
will
be
the
same.
The
certain
part
like
the
web
hook.
You
probably
will
always
need
some
web
hook,
the
so
some
of
the
code,
no
matter
which
way
you
go.
You
probably
won't
need
to
use
that
anyway,
so
some
part
can
probably
stay
it's
just
to
the
you
know
the
the
beginning
part
like.
How
do
we
introduce
this?
It
should
just
be
a
like
a
cr
targeted
crd.
A
You
see
like
this
way,
or
I
mean
this
one.
I
yeah
and
I
don't
think
but
but
we
can
definitely
we
can
do
some,
maybe
prototyping
and
then-
and
if
you
don't
oh,
what's
up
or
young.
H
A
Yeah,
that's
that's
what
we
talked
about
last
time
right,
so
we
we
went
to,
we
went
to
seek,
we
went
to
seek
off
okay,
I
think
we
have
some.
We
have
some
notes
somewhere
where's
the
notes
ronak.
H
A
We
can
you
know
what
I
think
we
can
probably
go
back
to
see
god's
meeting
and
ask
and
see
what
do
they
think
because
they,
you
know
they
are
familiar
with
this
type
of
things.
I
still
think
like.
Maybe
some
type
some
kind
of
a
poc
would
help,
because
I
think
some
of
the
core
part
of
that
controller,
the
web
hook.
You
will
need
it
anyway
in
any
case,
so
we
can.
We
can
think
about
this
one.
What
do
we
just
want
to
go
talk
about
this
again?
That's
fine
too.
A
G
So
I
I
don't
know
how
many
of
you
have
actually
tried
the
new
pod
security
admission
mechanism,
but
it's
based
on
like
setting
a
default
policy
in
in
the
config
file
for
the
for
the
controller,
and
then
you
set
labels
on
your
namespaces
and
the
labels
in
the
namespaces
are
authoritative
for
who
can
do
what
and
it's
it's
at
the
namespace
granularity,
the
new
mechanism?
It's
not
based
on
users.
So
anyone
who
can
create
a
pod
in
a
particular
name
space
is
subject
to
the.
A
That's
why
jordan
says
that's
not
going
to
work,
because
we
actually,
if
it's
just
a
because
we
can't
separate
a
like
a
like
a
if
it's
just
namespace
based,
we
can
say:
okay,
this
person
can
use
this
all.
A
A
Yeah,
so
basically
we,
okay,
so
just
to
answer
young's
question,
because
this
is
the
stick
stickers
meeting
notes
where
we
went
there.
Last
time
talked
about
this.
We
we
were
at
that
time,
proposing
to
do
this
for
security
on
the
what
insecurity
standard.
So
there's
one
reason
that
I
just
we
just
talked
about
earlier-
that
you
can't
just
just
check
that
at
namespace.
A
That's
not
going
to
be
enough,
so
jordan,
basically
saying
hey
you're,
trying
to
also
that
another
thing
he
was
saying
is
you're
trying
to
use
this
very,
very
complicated
approach
and
to
solve
this
one
particular
use
case.
It's
not
like
their
case
part
security
standard.
They
they
have
a
lot
of
use
cases
they
want
to
solve,
and
then
he
was
saying
why
don't
we
just
do
something
more
simple
that
he's
suggesting
is
just
to
have
the
control
at
the
cluster
level.
So
he
asked
us
whether
we
have
a
cluster
level
object
that
we
can
use.
A
In
our
cases
the
running
snapshot
content
so
basically
just
to
look
at.
So
that's
why
I
think
in
last.
A
A
Okay,
so
so,
basically
just
to
to
check
if
the
user,
if
if
the
user
is
allowed
to
do
this
conversion
and
then
look
how
the
the
volume
mode
matches
right,
so
I
mean
what
look
at
the
volume
mode
is
different
or
the
same
and
then
see
whether
that's
allowed
or
not.
So
he
was
basically
just
saying
hey.
Why
don't
just
do
a
user
web
hook
and
then
having
that
controlled
by
the
you
know,
cluster
scope
resource?
You
can
have
that.
So
that's.
A
Why
last
time
the
proposals
in
that
proposal,
we
added
that
as
an
annotation,
but
then
then
we're
saying
yeah
the
annotation.
We
can
see
that
it's
easy
to
be
changed,
so
it's
probably
better
to
have
a
crd
to
have
all
the
information
stored
so
yeah,
so
so
that's
actually
so
so
the
general
direction
from
seek
off
is
just
to
do
this
with
a
webhook
and
then
you
know
use
the
cluster
scoped
resource
gg
control,
because
that
level
is
your.
Is
your
admin.
H
What
clusters
called
the
resource?
Oh.
A
A
Let's,
let's,
let's
look
at
this
where's
that
this
one,
this
one,
I
think
right,
ronald
you
want
to
go
over
this
one.
This
is
the
previous
the
last
time
they
appreciate.
A
H
Well,
like
at
the
admission,
you
can
do
crazy
things.
You
could
check
if
the
user,
who
is
restoring
the
pvc,
restoring
the
snapshot,
for
example,
if
the
user
can
modify
the
volume
snapshot,
content
without
modifying.
H
Can
you
please
let
me
finish:
okay,
please
admission.
The
external
provisioner
can
check
if
the
user,
who
is
going
to
restore
the
snapshot
if
he
is
able
or
if
the
user
is
able
to
modify
volume,
censored
content
before
modifying
it.
Just
you
check
the
permission
and
if
the
user
has
this
permission,
which
is
pretty
huge
permission,
we
can
allow
cross
volume
mode,
restore.
H
A
Okay,
but
I
mean,
but
we
still
need
to
have
this-
we
still
need
to
differentiate
the
users
right,
otherwise,
yeah
yeah.
G
So
the
idea
is
that
the
admission
motorbook
would
veto
the
creation
request.
If,
if
it
tried
to
change
the
mode-
and
you
weren't
allowed
to
do
so
yeah,
so
you
can't
create
it
and
the
the
snapshot
would
never
never
land.
A
H
H
G
F
H
G
H
H
Yeah,
but
if
you
have
a
backup
software
that
flips
the
mode
the
user
can
use,
who
can
read
the
volume
such
as
content?
Not
right
can
detect
that
and
they
could
try
to
restore
wrong
snapshot
and
do
bad
things.
To
a
note.
F
I
understand,
but
what
you're
saying
is
you're
going
to
gate
the
change
on
the
ability
to
write
to
the
volume
snapshot
content?
Yes,
why
not
just
make
it
that,
in
order
to
make
the
change
you
have
to
write
to
the
volume
snapshot
content,
then
you
can
avoid
all
of
the
weirdness,
because
if,
if
we
allow.
F
G
F
F
F
G
H
D
H
A
A
H
H
G
A
G
G
H
A
H
H
F
F
D
F
So
I
I
think
the
the
basic
issue
is
as
a
non-privileged
user,
can
you
go
and
scribble
some
data
into
a
file
into
a
block
device
and
then
make
that
into
a
file
system
that
gets
mounted
and
possibly
crashes
or
exposes
some
other
security
vulnerability
in
the
system?
The
privileged
users
were
saying:
can
do
this
there's
any
number
of
ways
you
can
do
this?
You
can
do
this
by
static
provisioning.
F
G
F
B
A
A
H
Original,
well,
you
would
need
to
change
store
the
original
mode
somewhere
in
the
volume
content.
That's
exactly
what
I
was
saying,
yeah
exactly
and
then
allow
some.
A
A
A
So
like
this
one,
this
one
we
copied
from
the
original,
so
this
one
we
still
want
right.
We
still
need
that.
G
A
Come
in,
I
guess
I'm
not
not
really
getting
that.
I
think
we're
actually
running
out
of
time.
So
maybe
we
need
to
okay.
We
can
get
get
back
to
this
one
later,
all
right,
okay!
So
let's,
let's
get
back
to
this
one
later,
all
right
ironic!
I
don't
know
if
you'll
have
a
I
follow
this,
but
we,
I
think
we
need
to
maybe
come
back
and
see
what
exactly
young
is
proposing
and
then
see
how
that
will
work.
We
are
already
out
of
time.
A
So
all
right,
I
think
that's
that's
all
for
today,
then
thanks
everyone
bye.