flux-core icon indicating copy to clipboard operation
flux-core copied to clipboard

limit guest use of flux_kvs_txn_put_treeobj()

Open garlick opened this issue 3 years ago • 5 comments

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.

garlick avatar Mar 14 '22 22:03 garlick

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)

chu11 avatar Mar 17 '22 20:03 chu11

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.

garlick avatar Mar 17 '22 21:03 garlick

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.

garlick avatar Mar 18 '22 22:03 garlick

but can't a symlink "reference" something? and therefore something in the KVS should be preserved vs garbage collected?

chu11 avatar Mar 19 '22 00:03 chu11

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.

garlick avatar Mar 19 '22 04:03 garlick