yahoo-eng-team team mailing list archive

[Brian Rosmaita <rosmaita.fossdev@xxxxxxxxx>]

Public bug reported:

There is no DELETE implemented for the URI v2/tasks/{task_id}.  Instead,
when a task reaches a terminal status, it gets an 'expires_at'
datestamp.  (The task time-to-live is a config option, default is 48
hours.)  Tasks are soft deleted opportunistically as part of the task-
list call [0]; however, there is a check in the code that only (soft)
deletes the tasks that are owned by the user making the task-list call.
The problem is that in the interoperable image import workflow, the user
who makes the import call owns the task, but by default, this user does
not have access to the Tasks API calls, which are governed by the
"tasks_api_access" policy.  What will happen is that when an admin does
the task-list call, all tasks will be displayed, and the expired ones
will *not* be soft deleted because the admin does not own them.

The fix is probably simply to remove the ownership check in the
_task_soft_delete function.  This will be fine even for installations
that decide to allow all users access to the Tasks API.  After all, when
user A's tasks have expired, the next time user A makes a task-list
call, those tasks won't be seen.  So who cares if those expired tasks
are removed when user B makes a task-list call before user A does?
(User B isn't going to see them, they will just be soft deleted.)  The
key thing is that expired tasks will disappear sometime after they
expire but before user A receives a task-list response, just as they are
now.

The point of the "opportunistic" deletion strategy was so that there
wouldn't be a need to have some daemon continually polling the database
to soft delete expired tasks.  So I don't think there is a need to check
task ownership.


[0] https://github.com/openstack/glance/blob/418488ff2d40b60ad44484e9f1a0660cdbb17331/glance/db/sqlalchemy/api.py#L1503

** Affects: glance
     Importance: Undecided
         Status: Triaged

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1749310

Title:
  task soft deletion doesn't work when only admin has tasks_api_access
  permission

Status in Glance:
  Triaged

Bug description:
  There is no DELETE implemented for the URI v2/tasks/{task_id}.
  Instead, when a task reaches a terminal status, it gets an
  'expires_at' datestamp.  (The task time-to-live is a config option,
  default is 48 hours.)  Tasks are soft deleted opportunistically as
  part of the task-list call [0]; however, there is a check in the code
  that only (soft) deletes the tasks that are owned by the user making
  the task-list call.  The problem is that in the interoperable image
  import workflow, the user who makes the import call owns the task, but
  by default, this user does not have access to the Tasks API calls,
  which are governed by the "tasks_api_access" policy.  What will happen
  is that when an admin does the task-list call, all tasks will be
  displayed, and the expired ones will *not* be soft deleted because the
  admin does not own them.

  The fix is probably simply to remove the ownership check in the
  _task_soft_delete function.  This will be fine even for installations
  that decide to allow all users access to the Tasks API.  After all,
  when user A's tasks have expired, the next time user A makes a task-
  list call, those tasks won't be seen.  So who cares if those expired
  tasks are removed when user B makes a task-list call before user A
  does?  (User B isn't going to see them, they will just be soft
  deleted.)  The key thing is that expired tasks will disappear sometime
  after they expire but before user A receives a task-list response,
  just as they are now.

  The point of the "opportunistic" deletion strategy was so that there
  wouldn't be a need to have some daemon continually polling the
  database to soft delete expired tasks.  So I don't think there is a
  need to check task ownership.

  
  [0] https://github.com/openstack/glance/blob/418488ff2d40b60ad44484e9f1a0660cdbb17331/glance/db/sqlalchemy/api.py#L1503

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1749310/+subscriptions