public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/2] add_key05: Avoid race with key garbage collection
Date: Wed, 8 Apr 2020 06:19:04 -0400 (EDT)	[thread overview]
Message-ID: <1200091233.7615565.1586341144193.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <d950a46d-b65a-ac33-e71b-f93a2dce7620@cn.fujitsu.com>



----- Original Message -----
> Hi Richard
> 
> > The key subsystem independently tracks user info against UID. If a user is
> > deleted and the UID reused for a new user then the key subsystem will
> > mistake
> > the new user for the old one.

Thanks for raising this problem Richard. This matches CKI failure
we seen recently. (CC Li and Rachel)

> Does any documentation or kernel comment mentioned this? I didn't notice
> this before.
> > 
> > The keys/keyrings may not be accessible to the new user, but if they are
> > not
> > yet garbage collected (which happens asynchronously) then the new user may
> > be
> > exceeding its quota limits.
> > 
> > This results in a race condition where this test can fail because the old
> > thread keyring is taking up the full quota. We should be able to avoid this
> > by
> > creating two users in parallel instead of sequentially so that they have
> > different UIDs.
> I guess you may want to creat two user, so next, the key subsystem
> think the new user is different from  the last deleting user. It can
> avoid race.
> 
> But you patch overrides ltpuser, in actually, we still use
> ltp_add_key05_1 in SAFE_SETUID.
> 
> Also, this patch doesn't handle delete user when we using -i parameters.

-i might be problem, but other than that I think it works, at least for default run.

Though I'm wondering, shouldn't the test delete keys it creates,
rather than relying on garbage collection?


  reply	other threads:[~2020-04-08 10:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08  9:06 [LTP] [PATCH 1/2] add_key05: Avoid race with key garbage collection Richard Palethorpe
2020-04-08  9:06 ` [LTP] [PATCH 2/2] add_key05: Correct formatting Richard Palethorpe
2020-04-08  9:19   ` Yang Xu
2020-04-08  9:51 ` [LTP] [PATCH 1/2] add_key05: Avoid race with key garbage collection Yang Xu
2020-04-08 10:19   ` Jan Stancek [this message]
2020-04-08 11:01     ` Richard Palethorpe
2020-04-08 11:18       ` Jan Stancek
2020-04-08 11:40         ` Richard Palethorpe
2020-04-08 13:36           ` Richard Palethorpe
2020-04-09 11:32             ` Jan Stancek
2020-04-08 10:54   ` Richard Palethorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1200091233.7615565.1586341144193.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox