Sage Weil wrote: > On Fri, 25 Jul 2014, Daniel Hofmann wrote: >> The main issue however is not the hash's strength, but the fact that >> once pre-computed, I'm able to use preimages on **every Ceph cluster out >> there**. (As the hash functions's output is a deterministic function of >> the object's name only) >> >> I agree in that the general issue is inherent in hash-placement systems. >> >> But what I don't agree with is the following: >> >> Why do I have to be able to calculate my object's placement for **every >> Ceph cluster** out there? >> >> Why does it not suffice for me to be able to calculate the placement >> only for the cluster I'm currently accessing? >> >> >From a logical standpoint it seems reasonable. Why then, are we not able >> to constrain the placement calculation in that regard? >> >> >> If the placement is bound to a specific cluster it should suffice to >> derive e.g. a key for SipHash based on cluster specifics. >> >> Is this doable from an implementation point of view? >> >> >> Note: I only did this as a proof-of-concept for the object store. >> Think about the implications, if you're able to do this e.g. for every >> RadosGW out there and servies using RadosGW. > > It would be really easy to add a random salt to the pg_pool_t and feed > that into the object -> pg hash mapping. Note, by the way, that for new > clusters the pool id is already fed in here, so there is a *tiny* bit of > variation depending on what orders the pools were created in (although > probably not enough to meaningfully improve security). I just had a thought - is the FSID a parameter? If it is, then there's actually no need for a further salt: FSID is per cluster, preventing cross- cluster precomputation, and if the pool ID is fed in then each pool needs collisions calculated separately as well. In other words, the (fsid, poolid) tuple is almost certainly sufficient salt in and of itself. > We could also add a new hash type that is more secure. Rjenkins is used > by default but the choice of hash is already parameterized. > > sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
