flux-core
flux-core copied to clipboard
limit guest use of flux_kvs_txn_put_treeobj()
Problem: a guest user in the system instance can commit incorrect metadata to their private job namespace using flux_kvs_txn_put_treeobj().
As discussed in #4217, when the private job namespace is linked back into the primary namespace when the job goes inactive, any bad metadata becomes part of the primary namespace.
Such problems might include
- valref or dirref pointer to nonexistent blobref(s)
- dirref pointer to blobref for root or another parent directory, creating a cycle (edit: maybe impossible, see #4217)
- dirref pointer to an invalid dir object
- dirref pointer to a previous root or otherwise referencing a large amount of data preventing it from being removed by dump/restore.
@chu11 suggested that maybe we could limit access to that particular operation when guests attempt it.
Since all operations in a transaction look like (key, treeobj) tuples, I guess the limitation on the kvs end would need to be the type of treeobj.
Such problems might include
Also symlink infinite loops. i.e. errno = ELOOP
Since all operations in a transaction look like (key, treeobj) tuples, I guess the limitation on the kvs end would need to be the type of treeobj.
Unfortunately, we probably want to allow users to do symlinks, as it can be useful.
A potentially stupid solution would be to just make sure an ELOOP is never introduced. I.e. walk the symlink that is created. (this seems non-good ... just throwing it out there just b/c)
Meh I'd say don't let guests make symlinks if it simplifies our lives. The main use case is linking from primary namespace to a "live" job namespace.
Wait, I'm not sure a loopy or dangling symlink is a problem. It's definitely not a problem for flux-dump and flux-restore since they never follow them.
In regular file systems, I think of symlink targets more as "user data" than metadata. You can put anything you want there.
but can't a symlink "reference" something? and therefore something in the KVS should be preserved vs garbage collected?
Kind of a gray area, but generally file system archive programs like tar do not do that unless you specifically request it, and if backing up a system as root you would not request it because then any user can send your traversal anywhere they want.