From: Tyler Hicks <tyhicks@canonical.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files
Date: Fri, 22 Jun 2012 10:58:09 -0700 [thread overview]
Message-ID: <20120622175808.GA24984@boyd> (raw)
In-Reply-To: <CA+1xoqeJ8j5Dp1C6QtEvHhQVcVUKsCVCGhXVcceH9b669nEYAw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
On 2012-06-22 19:47:35, Sasha Levin wrote:
> On Wed, Jun 13, 2012 at 2:05 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
> > File operations on /dev/ecryptfs would BUG() when the operations were
> > performed by processes other than the process that originally opened the
> > file. This could happen with open files inherited after fork() or file
> > descriptors passed through IPC mechanisms. Rather than calling BUG(), an
> > error code can be safely returned in most situations.
> >
> > In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
> > release even if the last file reference is being held by a process that
> > didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
> > be successful, so a pointer to the daemon is stored in the file's
> > private_data. The private_data pointer is initialized when the miscdev
> > file is opened and only used when the file is released.
> >
> > https://launchpad.net/bugs/994247
> >
> > Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
> > Reported-by: Sasha Levin <levinsasha928@gmail.com>
> > Cc: Sasha Levin <levinsasha928@gmail.com>
> > ---
>
> I've been running it a while now and haven't seen the problem I've
> reported reproducing.
Thanks for the testing!
>
> Is it possible to merge this fix into 3.5?
That's my plan. I'll target this bug fix and the 2nd patch that removes
unused code for 3.5. I'll wait for 3.6 to merge the third patch.
Tyler
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-22 17:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-26 19:39 ecryptfs: kernel BUG at fs/ecryptfs/miscdev.c:52 Sasha Levin
2012-06-07 0:41 ` Sasha Levin
2012-06-13 0:05 ` [PATCH 0/3] eCryptfs: Fix and simplify messaging code Tyler Hicks
2012-06-13 0:05 ` [PATCH 1/3] eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files Tyler Hicks
2012-06-22 17:47 ` Sasha Levin
2012-06-22 17:58 ` Tyler Hicks [this message]
2012-06-13 0:05 ` [PATCH 2/3] eCryptfs: Remove unused messaging declarations and function Tyler Hicks
2012-06-13 0:05 ` [PATCH 3/3] eCryptfs: Make all miscdev functions use daemon ptr in file private_data Tyler Hicks
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=20120622175808.GA24984@boyd \
--to=tyhicks@canonical.com \
--cc=ecryptfs@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).