Directory rename semantics.

[Edward Tomasz Napierala]

On 1107T1110, Ceri Davies wrote:
> > > After discussion about this with rwatson and pjd, I decided to do
> > > the opposite: change ZFS behaviour to match UFS.  Reason is simple:
> > > this is security, and we want to be conservative here.  It's impossible
> > > to make sure this change wouldn't cause security problems.
> > 
> > Perhaps it would have been better to either do nothing or create a zfs
> > property that toggled this behaviour so that people who expect ZFS to
> > behave a certain way get it.  I'm not sure why we would want all
> > filesystems to behave the same way, to be honest.

Because of consistency.  Having different access rights behaviour
in different filesystems under the same operating system is confusing.

> I'm essentially unhappy here that a change to UFS which is local to us
> was considered important enough to ask -arch about, while ZFS which
> exists on at least two other operating systems was deemed fine to go
> ahead and change without review.

The change to UFS changes behaviour that 'was always there'.  Also,
it changes the behaviour to more permissive.  On the other hand, change
to ZFS is just another fix to make its semantics match ours.  Not the
first one - our ZFS behaves differently from ZFS under SunOS in other
places, e.g. newly created files inherit their group from the parent
directory.  Also, the change makes it more restrictive.

Sure, I can make it controllable via sysctl or a property.  However,
that would increase complexity - and the risk of security problems - even
more, for a very little in return (how many people actually _know_
about this check?).

Also, it _was_ reviewed.  Just not here.  ;-)

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?