[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

  Hello,

  OCFS2 mount option 'acl' is a small trap for users. When xattr feature
is not enabled and 'acl' mount option is specified, it is just silently
cleared during mount. IMHO that's not a good behavior - when admin requests
ACLs and we are not able to provide them, we should just fail the mount.
The trap is even more dangerous because the mount command is not aware that
we've cleared the 'acl' mount option and thus it records in /etc/mtab that
the filesystem is mounted with 'acl' mount option. So the output of mount
command looks as if ACLs were really in use. The only way to find out they
are not is to look into /proc/mounts or to try to get/set some ACL.
  Attached patch makes the mount fail if 'acl' mount option is specified
but xattr feature is disabled.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ocfs2-Fail-the-mount-when-acl-mount-option-is-spe.patch
Type: text/x-patch
Size: 2512 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20090914/bef0a2a5/attachment.bin 

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Mon, Sep 14, 2009 at 04:56:22PM +0200, Jan Kara wrote:
>   OCFS2 mount option 'acl' is a small trap for users. When xattr feature
> is not enabled and 'acl' mount option is specified, it is just silently
> cleared during mount. IMHO that's not a good behavior - when admin requests
> ACLs and we are not able to provide them, we should just fail the mount.

	See
http://www.mail-archive.com/ocfs2-devel at oss.oracle.com/msg03836.html for
previous discussion.

Joel

-- 

Life's Little Instruction Book #450

	"Don't be afraid to say, 'I need help.'"

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

On Mon 14-09-09 12:44:05, Joel Becker wrote:
> On Mon, Sep 14, 2009 at 04:56:22PM +0200, Jan Kara wrote:
> >   OCFS2 mount option 'acl' is a small trap for users. When xattr feature
> > is not enabled and 'acl' mount option is specified, it is just silently
> > cleared during mount. IMHO that's not a good behavior - when admin requests
> > ACLs and we are not able to provide them, we should just fail the mount.
> 
> 	See
> http://www.mail-archive.com/ocfs2-devel at oss.oracle.com/msg03836.html for
> previous discussion.
  Thanks for the pointer. I didn't know about this discussion. Actually,
this is a bit different situation because you won't so easily disable the
feature on the filesystem as opposed to just booting a kernel without ACL
support.
  Also filesystems like ext3/ext4/reiserfs just silently enable the XATTR
feature when you use is for the first time and the kernel supports it (for
these filesystems XATTRs are implemented as COMPAT features). OCFS2 will
fail the syscall (and it cannot really silently enable the feature because
it is an INCOMPAT one) so that's a difference anyway... So I still think
my change makes sence.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Mark Fasheh]

On Tue, Sep 15, 2009 at 11:24:24AM +0200, Jan Kara wrote:
> On Mon 14-09-09 12:44:05, Joel Becker wrote:
> > On Mon, Sep 14, 2009 at 04:56:22PM +0200, Jan Kara wrote:
> > >   OCFS2 mount option 'acl' is a small trap for users. When xattr feature
> > > is not enabled and 'acl' mount option is specified, it is just silently
> > > cleared during mount. IMHO that's not a good behavior - when admin requests
> > > ACLs and we are not able to provide them, we should just fail the mount.
> > 
> > 	See
> > http://www.mail-archive.com/ocfs2-devel at oss.oracle.com/msg03836.html for
> > previous discussion.
>   Thanks for the pointer. I didn't know about this discussion. Actually,
> this is a bit different situation because you won't so easily disable the
> feature on the filesystem as opposed to just booting a kernel without ACL
> support.
>   Also filesystems like ext3/ext4/reiserfs just silently enable the XATTR
> feature when you use is for the first time and the kernel supports it (for
> these filesystems XATTRs are implemented as COMPAT features). OCFS2 will
> fail the syscall (and it cannot really silently enable the feature because
> it is an INCOMPAT one) so that's a difference anyway... So I still think
> my change makes sence.

Another thing to consider is which scenario is more likely - a user
compiling their kernel without acl support (because really, all major
distros have this turned on), or a user mounts an existing (nor newly
created with the wrong mkfs options) ocfs2 file system with '-oacl' that
doesn't have acl turned on in the feature flags.

Regarding other file systems, I really wish we could do it their way, but as
Jan points out we can't magically enable acls like they can and we
definitely can't assume they're always on. So really, today's behavior is
*NOT* like those file systems in the first place - instead of magically
enabling the feature, we silently ignore the acl flag.
	--Mark

--
Mark Fasheh

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

On Thu 17-09-09 16:00:37, Mark Fasheh wrote:
> On Tue, Sep 15, 2009 at 11:24:24AM +0200, Jan Kara wrote:
> > On Mon 14-09-09 12:44:05, Joel Becker wrote:
> > > On Mon, Sep 14, 2009 at 04:56:22PM +0200, Jan Kara wrote:
> > > >   OCFS2 mount option 'acl' is a small trap for users. When xattr feature
> > > > is not enabled and 'acl' mount option is specified, it is just silently
> > > > cleared during mount. IMHO that's not a good behavior - when admin requests
> > > > ACLs and we are not able to provide them, we should just fail the mount.
> > > 
> > > 	See
> > > http://www.mail-archive.com/ocfs2-devel at oss.oracle.com/msg03836.html for
> > > previous discussion.
> >   Thanks for the pointer. I didn't know about this discussion. Actually,
> > this is a bit different situation because you won't so easily disable the
> > feature on the filesystem as opposed to just booting a kernel without ACL
> > support.
> >   Also filesystems like ext3/ext4/reiserfs just silently enable the XATTR
> > feature when you use is for the first time and the kernel supports it (for
> > these filesystems XATTRs are implemented as COMPAT features). OCFS2 will
> > fail the syscall (and it cannot really silently enable the feature because
> > it is an INCOMPAT one) so that's a difference anyway... So I still think
> > my change makes sence.
> 
> Another thing to consider is which scenario is more likely - a user
> compiling their kernel without acl support (because really, all major
> distros have this turned on), or a user mounts an existing (nor newly
> created with the wrong mkfs options) ocfs2 file system with '-oacl' that
> doesn't have acl turned on in the feature flags.
> 
> Regarding other file systems, I really wish we could do it their way, but as
> Jan points out we can't magically enable acls like they can and we
> definitely can't assume they're always on. So really, today's behavior is
> *NOT* like those file systems in the first place - instead of magically
> enabling the feature, we silently ignore the acl flag.
  Joel, so what is your final decision? I still think we should fail the
mount when acl mount option is specified but xattr feature is disabled...
  Should I resend the patch?

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Tue, Oct 06, 2009 at 07:17:43PM +0200, Jan Kara wrote:
> On Thu 17-09-09 16:00:37, Mark Fasheh wrote:
> > On Tue, Sep 15, 2009 at 11:24:24AM +0200, Jan Kara wrote:
> > > On Mon 14-09-09 12:44:05, Joel Becker wrote:
> > > > On Mon, Sep 14, 2009 at 04:56:22PM +0200, Jan Kara wrote:
> > > > >   OCFS2 mount option 'acl' is a small trap for users. When xattr feature
> > > > > is not enabled and 'acl' mount option is specified, it is just silently
> > > > > cleared during mount. IMHO that's not a good behavior - when admin requests
> > > > > ACLs and we are not able to provide them, we should just fail the mount.
> > > > 
> > > > 	See
> > > > http://www.mail-archive.com/ocfs2-devel at oss.oracle.com/msg03836.html for
> > > > previous discussion.

	Checked the discussion again.  What really struck me was:

            Chris and Cristoph pointed out that btrfs and xfs always
    assume '-o acl,user_xattr' if the feature is compiled in.  They are
    always on.  btrfs only disables acls with '-o noacl'.  Might be
    worth considering.

> > >   Also filesystems like ext3/ext4/reiserfs just silently enable the XATTR
> > > feature when you use is for the first time and the kernel supports it (for
> > > these filesystems XATTRs are implemented as COMPAT features). OCFS2 will
> > > fail the syscall (and it cannot really silently enable the feature because
> > > it is an INCOMPAT one) so that's a difference anyway... So I still think
> > > my change makes sence.

	Sure, you can't enable INCOMPAT features.  But you can use them
if they are already enabled.  Why can't we just use acls when the driver
supports them and the filesystem has xattrs already?

> > Another thing to consider is which scenario is more likely - a user
> > compiling their kernel without acl support (because really, all major
> > distros have this turned on), or a user mounts an existing (nor newly
> > created with the wrong mkfs options) ocfs2 file system with '-oacl' that
> > doesn't have acl turned on in the feature flags.

	The big boundary for the naive user is probably 1.6.  It has
xattrs and 1.4 does not.  SLES has it easier, because the boundary is
sles10->sles11.  EL5 will have both 1.4 and 1.6.  But that's OK in
either fashion, probably, because if you want to go back to 1.4 you have
to turn off xattrs.  So why not assume that if you have xattrs, you can
just turn on acls?

> > Regarding other file systems, I really wish we could do it their way, but as
> > Jan points out we can't magically enable acls like they can and we
> > definitely can't assume they're always on. So really, today's behavior is
> > *NOT* like those file systems in the first place - instead of magically
> > enabling the feature, we silently ignore the acl flag.

	Actually, I just realized where we really differ from the other
filesystems.  We're clustered, but CONFIG_OCFS2_POSIX_ACL isn't a
feature flag.  We can, in theory, have two nodes.  Both have xattrs
enabled, but only one has acls compiled into the kernel.  Now we're
fucked.
	As far as I can tell, there is no way for the non-acl driver to
notice that other nodes are using acls and reject the mount.  Thoughts?

Joel

-- 

"Anything that is too stupid to be spoken is sung."  
        - Voltaire

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

On Tue 13-10-09 12:46:16, Joel Becker wrote:
> On Tue, Oct 06, 2009 at 07:17:43PM +0200, Jan Kara wrote:
> > On Thu 17-09-09 16:00:37, Mark Fasheh wrote:
> > > On Tue, Sep 15, 2009 at 11:24:24AM +0200, Jan Kara wrote:
> > > > On Mon 14-09-09 12:44:05, Joel Becker wrote:
> > > > > On Mon, Sep 14, 2009 at 04:56:22PM +0200, Jan Kara wrote:
> > > > > >   OCFS2 mount option 'acl' is a small trap for users. When xattr feature
> > > > > > is not enabled and 'acl' mount option is specified, it is just silently
> > > > > > cleared during mount. IMHO that's not a good behavior - when admin requests
> > > > > > ACLs and we are not able to provide them, we should just fail the mount.
> > > > > 
> > > > > 	See
> > > > > http://www.mail-archive.com/ocfs2-devel at oss.oracle.com/msg03836.html for
> > > > > previous discussion.
> 
> 	Checked the discussion again.  What really struck me was:
> 
>             Chris and Cristoph pointed out that btrfs and xfs always
>     assume '-o acl,user_xattr' if the feature is compiled in.  They are
>     always on.  btrfs only disables acls with '-o noacl'.  Might be
>     worth considering.
> 
> > > >   Also filesystems like ext3/ext4/reiserfs just silently enable the XATTR
> > > > feature when you use is for the first time and the kernel supports it (for
> > > > these filesystems XATTRs are implemented as COMPAT features). OCFS2 will
> > > > fail the syscall (and it cannot really silently enable the feature because
> > > > it is an INCOMPAT one) so that's a difference anyway... So I still think
> > > > my change makes sence.
> 
> 	Sure, you can't enable INCOMPAT features.  But you can use them
> if they are already enabled.  Why can't we just use acls when the driver
> supports them and the filesystem has xattrs already?
  We can but that's a bit separate issue. What I'm advocating is:
When user explicitely asks for acls via a mount option and the filesystem
does not have the feature enabled, just fail the mount instead of ignoring
the 'acl' mount option.
  Behavior that makes most sence to me is - when user does not specify any
particular mount option, use acls iff the filesystem has the feature
enabled.
  When user specifies 'acl' mount option, fail the mount if the filesystem
does not have the feature enabled or kernel is not able to support acls,
otherwise mount the filesystem with acls.
  When user specifies 'noacl', don't use acls (but see below).

> > > Regarding other file systems, I really wish we could do it their way, but as
> > > Jan points out we can't magically enable acls like they can and we
> > > definitely can't assume they're always on. So really, today's behavior is
> > > *NOT* like those file systems in the first place - instead of magically
> > > enabling the feature, we silently ignore the acl flag.
> 
> 	Actually, I just realized where we really differ from the other
> filesystems.  We're clustered, but CONFIG_OCFS2_POSIX_ACL isn't a
> feature flag.  We can, in theory, have two nodes.  Both have xattrs
> enabled, but only one has acls compiled into the kernel.  Now we're
> fucked.
> 	As far as I can tell, there is no way for the non-acl driver to
> notice that other nodes are using acls and reject the mount.  Thoughts?
  Hmm, this is nasty. I see two possible solutions:
a) Use acls iff xattr feature is enabled (i.e., mount options do not
influence whether acls are used or not), don't let kernel without
CONFIG_OCFS2_POSIX_ACL mount the filesystem with xattr feature enabled.
That should guarantee consistency among nodes but it can be inconvenient
at times (you'd have to disable xattrs via tunefs.ocfs2 to temporarily
disable acls and thus you'd loose all acl settings).

b) Introduce superblock bit 'mounted_with_acls'. The first node in the
cluster either sets this bit or leaves it zero. Other nodes then refuse
to mount the filesystem inconsistently with the bit setting (so if the bit
is set, nodes without CONFIG_OCFS2_POSIX_ACL cannot mount the fs).

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Tue, Oct 13, 2009 at 10:12:10PM +0200, Jan Kara wrote:
>   We can but that's a bit separate issue. What I'm advocating is:
> When user explicitely asks for acls via a mount option and the filesystem
> does not have the feature enabled, just fail the mount instead of ignoring
> the 'acl' mount option.

	I understand the origin of your patch.  I just think we need to
consider the overall behavior so we can have a consistent story.  Don't
worry, it probably involves rejecting -oacl when we can't support it.

> > 	As far as I can tell, there is no way for the non-acl driver to
> > notice that other nodes are using acls and reject the mount.  Thoughts?
>   Hmm, this is nasty. I see two possible solutions:
> a) Use acls iff xattr feature is enabled (i.e., mount options do not
> influence whether acls are used or not), don't let kernel without
> CONFIG_OCFS2_POSIX_ACL mount the filesystem with xattr feature enabled.
> That should guarantee consistency among nodes but it can be inconvenient
> at times (you'd have to disable xattrs via tunefs.ocfs2 to temporarily
> disable acls and thus you'd loose all acl settings).
> 
> b) Introduce superblock bit 'mounted_with_acls'. The first node in the
> cluster either sets this bit or leaves it zero. Other nodes then refuse
> to mount the filesystem inconsistently with the bit setting (so if the bit
> is set, nodes without CONFIG_OCFS2_POSIX_ACL cannot mount the fs).

	Quick question: what happens on a filesystem that is run for a
little while without acls?  Eg, ext3?

    mount -oacl /dev/sda1 /ext3
    # do stuff
    umount /ext3
    mount -onoacl /dev/sda1 /ext3
    # do stuff
    umount /ext3
    mount -oacl /dev/sda1 /ext3

Is it totally screwed up?  Are the default acls sufficient such that
files created or modified while acls were off are in a sane state?
	If they are in a sane state, we can solve this with a cluster
lock.  It would require a minor revision of the locking protocol.  The
lock's LVB stores a simple boolean of whether ACLs are in use or not.
It is set by the first node.  Subsequent nodes would compare this
boolean against their acl support and continue or fail appropriately.
	If the first mounter doesn't support this lock (older locking
protocol), we simply honor the mount option as we have up until now.  If
the sysadmin mismatches acl and !acl nodes...their fault.

Joel

-- 

"Always give your best, never get discouraged, never be petty; always
 remember, others may hate you.  Those who hate you don't win unless
 you hate them.  And then you destroy yourself."
	- Richard M. Nixon

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

On Tue 13-10-09 13:43:37, Joel Becker wrote:
> On Tue, Oct 13, 2009 at 10:12:10PM +0200, Jan Kara wrote:
> > > 	As far as I can tell, there is no way for the non-acl driver to
> > > notice that other nodes are using acls and reject the mount.  Thoughts?
> >   Hmm, this is nasty. I see two possible solutions:
> > a) Use acls iff xattr feature is enabled (i.e., mount options do not
> > influence whether acls are used or not), don't let kernel without
> > CONFIG_OCFS2_POSIX_ACL mount the filesystem with xattr feature enabled.
> > That should guarantee consistency among nodes but it can be inconvenient
> > at times (you'd have to disable xattrs via tunefs.ocfs2 to temporarily
> > disable acls and thus you'd loose all acl settings).
> > 
> > b) Introduce superblock bit 'mounted_with_acls'. The first node in the
> > cluster either sets this bit or leaves it zero. Other nodes then refuse
> > to mount the filesystem inconsistently with the bit setting (so if the bit
> > is set, nodes without CONFIG_OCFS2_POSIX_ACL cannot mount the fs).
> 
> 	Quick question: what happens on a filesystem that is run for a
> little while without acls?  Eg, ext3?
> 
>     mount -oacl /dev/sda1 /ext3
>     # do stuff
>     umount /ext3
>     mount -onoacl /dev/sda1 /ext3
>     # do stuff
>     umount /ext3
>     mount -oacl /dev/sda1 /ext3
> 
> Is it totally screwed up?  Are the default acls sufficient such that
> files created or modified while acls were off are in a sane state?
  For ext3, when you mount with noacl, acls are not inherited for newly
created files and directories, obviously they are not enforced but
apart from that they stay correct.

> 	If they are in a sane state, we can solve this with a cluster
> lock.  It would require a minor revision of the locking protocol.  The
> lock's LVB stores a simple boolean of whether ACLs are in use or not.
> It is set by the first node.  Subsequent nodes would compare this
> boolean against their acl support and continue or fail appropriately.
> 	If the first mounter doesn't support this lock (older locking
> protocol), we simply honor the mount option as we have up until now.  If
> the sysadmin mismatches acl and !acl nodes...their fault.
  Yes, this looks like a reasonable choice.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Mark Fasheh]

On Wed, Oct 14, 2009 at 12:30:04AM +0200, Jan Kara wrote:
> > 	Quick question: what happens on a filesystem that is run for a
> > little while without acls?  Eg, ext3?
> > 
> >     mount -oacl /dev/sda1 /ext3
> >     # do stuff
> >     umount /ext3
> >     mount -onoacl /dev/sda1 /ext3
> >     # do stuff
> >     umount /ext3
> >     mount -oacl /dev/sda1 /ext3
> > 
> > Is it totally screwed up?  Are the default acls sufficient such that
> > files created or modified while acls were off are in a sane state?
>   For ext3, when you mount with noacl, acls are not inherited for newly
> created files and directories, obviously they are not enforced but
> apart from that they stay correct.

Thanks for clearing that up Jan.


> > 	If they are in a sane state, we can solve this with a cluster
> > lock.  It would require a minor revision of the locking protocol.  The
> > lock's LVB stores a simple boolean of whether ACLs are in use or not.
> > It is set by the first node.  Subsequent nodes would compare this
> > boolean against their acl support and continue or fail appropriately.
> > 	If the first mounter doesn't support this lock (older locking
> > protocol), we simply honor the mount option as we have up until now.  If
> > the sysadmin mismatches acl and !acl nodes...their fault.
>   Yes, this looks like a reasonable choice.

Hmm, regarding this part of the discussion - how do we know if the admin
actually wants the proposed behavior? Presumably the admin in our ext3
example has a good reason for working without acls for a time. Perhaps the
same admin would like that ability on a cluster node, without having to
unmount from all acl nodes in the cluster...

If we add cluster locking / messaging, etc to disallow this, we're removing
a potentially valid use case.
	--Mark


--
Mark Fasheh

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Tue, Oct 13, 2009 at 03:50:14PM -0700, Mark Fasheh wrote:
> Hmm, regarding this part of the discussion - how do we know if the admin
> actually wants the proposed behavior? Presumably the admin in our ext3
> example has a good reason for working without acls for a time. Perhaps the
> same admin would like that ability on a cluster node, without having to
> unmount from all acl nodes in the cluster...

	I would think anyone would want the acl behavior coherent across
the cluster.  Otherwise node 1 is setting an acl that node 2 promptly
ignores?  Yuk!  Especially since that admin could have accidentally
booted a non-ACL ocfs2 and not realize it?

> If we add cluster locking / messaging, etc to disallow this, we're removing
> a potentially valid use case.

	I don't know that it is valid.  But if we want to support it, we
can clearly differentiate between "my kernel doesn't support this" and
"I support it, but I was told noacl".

Joel

-- 

"Three o'clock is always too late or too early for anything you
 want to do."
        - Jean-Paul Sartre

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Mark Fasheh]

On Tue, Oct 13, 2009 at 04:02:41PM -0700, Joel Becker wrote:
> On Tue, Oct 13, 2009 at 03:50:14PM -0700, Mark Fasheh wrote:
> > Hmm, regarding this part of the discussion - how do we know if the admin
> > actually wants the proposed behavior? Presumably the admin in our ext3
> > example has a good reason for working without acls for a time. Perhaps the
> > same admin would like that ability on a cluster node, without having to
> > unmount from all acl nodes in the cluster...
> 
> 	I would think anyone would want the acl behavior coherent across
> the cluster.  Otherwise node 1 is setting an acl that node 2 promptly
> ignores?  Yuk!  Especially since that admin could have accidentally
> booted a non-ACL ocfs2 and not realize it?

Well, we have to ask ourselves what the (theoretical) person remounting ext3
without acls is doing that for. This isn't about the ext3 rules for mounting
with acls as much as it's a question of "why would this happen?".


> > If we add cluster locking / messaging, etc to disallow this, we're removing
> > a potentially valid use case.
> 
> 	I don't know that it is valid.  But if we want to support it, we
> can clearly differentiate between "my kernel doesn't support this" and
> "I support it, but I was told noacl".

Right, I am theorizing about the case of "I support it, but I was told
noacl" which I don't see a good reason to disallow (even if a mount is
mounted acl elsewhere)

It might make more sense to look at this from the other direction. Say I'm
a cluster admin and my nodes aren't currently using acls. Perhaps at some
point in the future, I want to enable them (maybe so I can deploy a new app
on my shared disk). Today, I could do this without taking down the entire
cluster - I'd simply enable acls one node at a time. Once they were all back
up with acl support, I could deploy my app without having lost any downtime.
If we disallow this situation, I'd have to bring down the entire cluster to
enable acls.

Considering how much time we put into online-fs-operations, I say we keep
this ability. We can market it as "Ocfs2 supports online acl enablement!" ;)


Btw, are we all agreed about Jan's original patch?
	--Mark

--
Mark Fasheh

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Tue, Oct 13, 2009 at 04:50:21PM -0700, Mark Fasheh wrote:
> On Tue, Oct 13, 2009 at 04:02:41PM -0700, Joel Becker wrote:
> > On Tue, Oct 13, 2009 at 03:50:14PM -0700, Mark Fasheh wrote:
> > > Hmm, regarding this part of the discussion - how do we know if the admin
> > > actually wants the proposed behavior? Presumably the admin in our ext3
> > > example has a good reason for working without acls for a time. Perhaps the
> > > same admin would like that ability on a cluster node, without having to
> > > unmount from all acl nodes in the cluster...
> > 
> > 	I would think anyone would want the acl behavior coherent across
> > the cluster.  Otherwise node 1 is setting an acl that node 2 promptly
> > ignores?  Yuk!  Especially since that admin could have accidentally
> > booted a non-ACL ocfs2 and not realize it?
> 
> Well, we have to ask ourselves what the (theoretical) person remounting ext3
> without acls is doing that for. This isn't about the ext3 rules for mounting
> with acls as much as it's a question of "why would this happen?".

	Sure.  And with ext3 it's probably "I forgot the option" because
it defaults to off.  With xfs, it would have to be a deliberate -onoacl.
Christoph, are you paying attention?  Any thoughts?

> > 	I don't know that it is valid.  But if we want to support it, we
> > can clearly differentiate between "my kernel doesn't support this" and
> > "I support it, but I was told noacl".
> 
> Right, I am theorizing about the case of "I support it, but I was told
> noacl" which I don't see a good reason to disallow (even if a mount is
> mounted acl elsewhere)

	That sort of thing fits obviously in the realm of "you asked for
it".  So it's only a question of effort vs need.  That is, we put in the
time to add the flexibility (and the potential confusion) because we
expect someone really has a valid use case.

> It might make more sense to look at this from the other direction. Say I'm
> a cluster admin and my nodes aren't currently using acls. Perhaps at some
> point in the future, I want to enable them (maybe so I can deploy a new app
> on my shared disk). Today, I could do this without taking down the entire
> cluster - I'd simply enable acls one node at a time. Once they were all back
> up with acl support, I could deploy my app without having lost any downtime.
> If we disallow this situation, I'd have to bring down the entire cluster to
> enable acls.

	Well, if we go to a "acls are on by default" scenario, they're
already on.  You just don't notice them because no one has used
setfacl() and the default acls match unix permissions ;-)  Turning it
"on" just means calling setfacl().
	The whole problem of "what to do when -oacl is specified" falls
out from our defaulting them off.  We're the only "modern" filesystem
that does that.

Joel

-- 

"Conservative, n.  A statesman who is enamoured of existing evils,
 as distinguished from the Liberal, who wishes to replace them
 with others."
	- Ambrose Bierce, The Devil's Dictionary

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Christoph Hellwig]

On Tue, Oct 13, 2009 at 12:46:16PM -0700, Joel Becker wrote:
> 	Actually, I just realized where we really differ from the other
> filesystems.  We're clustered, but CONFIG_OCFS2_POSIX_ACL isn't a
> feature flag.  We can, in theory, have two nodes.  Both have xattrs
> enabled, but only one has acls compiled into the kernel.  Now we're
> fucked.
> 	As far as I can tell, there is no way for the non-acl driver to
> notice that other nodes are using acls and reject the mount.  Thoughts?

So why do you allow compiling ocfs2 without ACLs at all?

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Wed, Oct 14, 2009 at 02:27:52AM +0200, Christoph Hellwig wrote:
> On Tue, Oct 13, 2009 at 12:46:16PM -0700, Joel Becker wrote:
> > 	Actually, I just realized where we really differ from the other
> > filesystems.  We're clustered, but CONFIG_OCFS2_POSIX_ACL isn't a
> > feature flag.  We can, in theory, have two nodes.  Both have xattrs
> > enabled, but only one has acls compiled into the kernel.  Now we're
> > fucked.
> > 	As far as I can tell, there is no way for the non-acl driver to
> > notice that other nodes are using acls and reject the mount.  Thoughts?
> 
> So why do you allow compiling ocfs2 without ACLs at all?

	You *are* paying attention :-)  I believe this is for hysterical
raisins.  We copied ext3 on this.  I'm totally in support of ripping
ACLs out of Kconfig.

Joel

-- 

"I almost ran over an angel
 He had a nice big fat cigar.
 'In a sense,' he said, 'You're alone here
 So if you jump, you'd best jump far.'"

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

On Tue 13-10-09 17:38:59, Joel Becker wrote:
> On Wed, Oct 14, 2009 at 02:27:52AM +0200, Christoph Hellwig wrote:
> > On Tue, Oct 13, 2009 at 12:46:16PM -0700, Joel Becker wrote:
> > > 	Actually, I just realized where we really differ from the other
> > > filesystems.  We're clustered, but CONFIG_OCFS2_POSIX_ACL isn't a
> > > feature flag.  We can, in theory, have two nodes.  Both have xattrs
> > > enabled, but only one has acls compiled into the kernel.  Now we're
> > > fucked.
> > > 	As far as I can tell, there is no way for the non-acl driver to
> > > notice that other nodes are using acls and reject the mount.  Thoughts?
> > 
> > So why do you allow compiling ocfs2 without ACLs at all?
> 
> 	You *are* paying attention :-)  I believe this is for hysterical
> raisins.  We copied ext3 on this.  I'm totally in support of ripping
> ACLs out of Kconfig.
  Yes, this would certainly simplify the situation. And looking at the
code, disabling CONFIG_OCFS2_POSIX_ACL does not seem to bring any
significant code-size or speed advantage... So I'm in favor of this.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Wed, Oct 14, 2009 at 11:41:29AM +0200, Jan Kara wrote:
> On Tue 13-10-09 17:38:59, Joel Becker wrote:
> > 	You *are* paying attention :-)  I believe this is for hysterical
> > raisins.  We copied ext3 on this.  I'm totally in support of ripping
> > ACLs out of Kconfig.
>   Yes, this would certainly simplify the situation. And looking at the
> code, disabling CONFIG_OCFS2_POSIX_ACL does not seem to bring any
> significant code-size or speed advantage... So I'm in favor of this.

	So let's do this:

1) Rip out CONFIG_OCFS2_POSIX_ACL.  The code is always built in.
2) Always enable acls if a filesystem has xattrs.  This is a noop if no
   one ever calls setacl.
3) If a user explicitly puts -oacl on the mount command line, but the
   filesystem doesn't have xattrs, fail the mount.  This is a safe place
   to catch people changing kernels, as a too-old kernel driver likely
   doesn't have xattrs anyway.
4) If a user explicitly puts -onoacl on the mount command line, they get
   what they asked for.

	This behavior matches the other 'modern' filesystems.  The only
weirdness is in the cluster case, and the most common users will be
using released versions with ACL support.  Anyone compiling recent
drivers or kernels can't leave the support out.
	Mark, Jan?

Joel

-- 

Life's Little Instruction Book #197

	"Don't forget, a person's greatest emotional need is to 
	 feel appreciated."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

On Wed 14-10-09 03:03:35, Joel Becker wrote:
> On Wed, Oct 14, 2009 at 11:41:29AM +0200, Jan Kara wrote:
> > On Tue 13-10-09 17:38:59, Joel Becker wrote:
> > > 	You *are* paying attention :-)  I believe this is for hysterical
> > > raisins.  We copied ext3 on this.  I'm totally in support of ripping
> > > ACLs out of Kconfig.
> >   Yes, this would certainly simplify the situation. And looking at the
> > code, disabling CONFIG_OCFS2_POSIX_ACL does not seem to bring any
> > significant code-size or speed advantage... So I'm in favor of this.
> 
> 	So let's do this:
> 
> 1) Rip out CONFIG_OCFS2_POSIX_ACL.  The code is always built in.
> 2) Always enable acls if a filesystem has xattrs.  This is a noop if no
>    one ever calls setacl.
> 3) If a user explicitly puts -oacl on the mount command line, but the
>    filesystem doesn't have xattrs, fail the mount.  This is a safe place
>    to catch people changing kernels, as a too-old kernel driver likely
>    doesn't have xattrs anyway.
> 4) If a user explicitly puts -onoacl on the mount command line, they get
>    what they asked for.
> 
> 	This behavior matches the other 'modern' filesystems.  The only
> weirdness is in the cluster case, and the most common users will be
> using released versions with ACL support.  Anyone compiling recent
> drivers or kernels can't leave the support out.
> 	Mark, Jan?
  Yes, this looks good to me.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Mark Fasheh]

On Wed, Oct 14, 2009 at 03:03:35AM -0700, Joel Becker wrote:
> On Wed, Oct 14, 2009 at 11:41:29AM +0200, Jan Kara wrote:
> > On Tue 13-10-09 17:38:59, Joel Becker wrote:
> > > 	You *are* paying attention :-)  I believe this is for hysterical
> > > raisins.  We copied ext3 on this.  I'm totally in support of ripping
> > > ACLs out of Kconfig.
> >   Yes, this would certainly simplify the situation. And looking at the
> > code, disabling CONFIG_OCFS2_POSIX_ACL does not seem to bring any
> > significant code-size or speed advantage... So I'm in favor of this.
> 
> 	So let's do this:
> 
> 1) Rip out CONFIG_OCFS2_POSIX_ACL.  The code is always built in.
> 2) Always enable acls if a filesystem has xattrs.  This is a noop if no
>    one ever calls setacl.
> 3) If a user explicitly puts -oacl on the mount command line, but the
>    filesystem doesn't have xattrs, fail the mount.  This is a safe place
>    to catch people changing kernels, as a too-old kernel driver likely
>    doesn't have xattrs anyway.
> 4) If a user explicitly puts -onoacl on the mount command line, they get
>    what they asked for.
> 
> 	This behavior matches the other 'modern' filesystems.  The only
> weirdness is in the cluster case, and the most common users will be
> using released versions with ACL support.  Anyone compiling recent
> drivers or kernels can't leave the support out.
> 	Mark, Jan?

Yes, yes, yes and yes.  ;)
	--Mark

--
Mark Fasheh

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Jan Kara]

On Wed 14-10-09 09:27:51, Mark Fasheh wrote:
> On Wed, Oct 14, 2009 at 03:03:35AM -0700, Joel Becker wrote:
> > On Wed, Oct 14, 2009 at 11:41:29AM +0200, Jan Kara wrote:
> > > On Tue 13-10-09 17:38:59, Joel Becker wrote:
> > > > 	You *are* paying attention :-)  I believe this is for hysterical
> > > > raisins.  We copied ext3 on this.  I'm totally in support of ripping
> > > > ACLs out of Kconfig.
> > >   Yes, this would certainly simplify the situation. And looking at the
> > > code, disabling CONFIG_OCFS2_POSIX_ACL does not seem to bring any
> > > significant code-size or speed advantage... So I'm in favor of this.
> > 
> > 	So let's do this:
> > 
> > 1) Rip out CONFIG_OCFS2_POSIX_ACL.  The code is always built in.
> > 2) Always enable acls if a filesystem has xattrs.  This is a noop if no
> >    one ever calls setacl.
> > 3) If a user explicitly puts -oacl on the mount command line, but the
> >    filesystem doesn't have xattrs, fail the mount.  This is a safe place
> >    to catch people changing kernels, as a too-old kernel driver likely
> >    doesn't have xattrs anyway.
> > 4) If a user explicitly puts -onoacl on the mount command line, they get
> >    what they asked for.
> > 
> > 	This behavior matches the other 'modern' filesystems.  The only
> > weirdness is in the cluster case, and the most common users will be
> > using released versions with ACL support.  Anyone compiling recent
> > drivers or kernels can't leave the support out.
> > 	Mark, Jan?
> 
> Yes, yes, yes and yes.  ;)
  OK, so should I implement it? Or Joel, will you take care of it?

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[Ocfs2-devel] [PATCH] [RFC] Mount option trap for users

[Joel Becker]

On Wed, Oct 14, 2009 at 08:11:48PM +0200, Jan Kara wrote:
>   OK, so should I implement it? Or Joel, will you take care of it?

	You already have half the patch, so it would be awesome if you
could finish it up.

Joel

-- 

Life's Little Instruction Book #222

	"Think twice before burdening a friend with a secret."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127