On Wed, Aug 06, 2014 at 04:43:31PM -0400, Jan Harkes wrote:
> On Wed, Aug 06, 2014 at 06:30:34PM +0200, u-codalist-z149_at_aetey.se wrote:
> > If possible and not too bothersome, I would be interested to look at
> > the corresponding code. Is it available?
> 
> I never had it in version control, not sure if I can find it. I am
> pretty sure I have upgraded my computer at least twice but the way disks
> get larger I tend to copy everything in my old home directory to a
> subdir on any new computer.

If you happen to come across it, I'd appreciate a copy.

> Also because it was proof of concept code, callback log storage on the
> servers was as far as I remember unbounded, with disconnections you
> cannot tell how long to keep these logs around. A solution for that is

Ah, I see, callbacks do not "grow" while the corresponding client is
inactive (e.g.  because it went disconnected) but the log grows all
the time and the server does not know when to drop the oldest entries.

> to have a ValidateAttrs fallback when the clients callback log sync
> timestamp is older than the oldest entry in the log.

IOW truncate according to some policy and let the clients detect
this and handle the consequences, looks reasonable.

On Wed, Aug 06, 2014 at 05:20:24PM -0400, Jan Harkes wrote:
> > When a client caches even a single object (the root) of a volume, it is
> > notified when any file in that volume changes and it has to download a
> > list of all file identifiers that were changed, whether or not the
> > client is even allowed to access those files.

Indeed, this implies cross-client and cross-identity leakage of change
notifications. To avoid this, every entry in the log would have to be
associated with a corresponding acl (which does not look too hard) and
the server would have to evaluate the acl for each entry (filter the log)
before shipping it to the client - this may be strenuous (?). The client
would have to fetch changes per identity which it has tokens for. Then
for my eyes it would look reasonably protected.

(If I understand correctly, we always have a single verifiable identity
corresponding to a connection, so the client would have to fetch change
notifications via multiple connections, per user identity, I guess this
would be the most intrusive part of a possible change.)

> Oh, right I forgot to say that this is a potential security issue
> because of the following scenario.
> 
> I have a volume with a default System:AnyUser rl ACL and I create a Mail
> subdirectory and set up the maildir folders Mail/{cur,new,tmp} Then I
> realize that I don't want the world to read my email so I remove the
> AnyUser ACL from Mail/.
> 
> With normal callbacks nobody can get past Mail/ and so nobody will 
> be able to see the vnode/uniquefier parts of the file ids and as such be
> unable to read my email.
> 
> With a callback log everyone who can access even a single object in the
> volume gets the file ids for my email and because the cur/new/tmp
> directories still give System:Anyuser access they have access it.

I fully agree leaking internal ids and the file changes information to
unrelated parties is unacceptable. On the other side protecting the file
ids is not a proper way to protect the file contents.

> So yes the original breakdown is the fact that the subdirectories didn't
> have appropriate ACLs, but it is not expected behaviour that someone can

Exactly.

> get past that protected parent directory so easily.

There are legitimate situations where you can very easily get "past" a
protected directory, e.g. if there is a mountpoint between the protected
directory and the sensitive data.

I do not see this as a security breach, it reflects merely a user's
[possible but] incorrect expectations that protecting a directory protects
the "whole" file tree behind it - it does not.

If the fids are not really random and large, then you can even blindly
[try to] access each of the objects in a volume, without any relation to
their position in the file tree. If the object's acl allows the access,
you get it.

This fact is not a security problem (to the contrary this reflects a
sound security model), while the user's misperception certainly is.

(I think it is useful to reiterate this for the casual readers's sake:

It is solely the acl on the object container directory which matters,
_not_ any acl on any other directory, even if higher up in the file tree.)

Rune