From: David Howells <dhowells@redhat.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: dhowells@redhat.com, jmalicki@metacarta.com, chrisw@sous-sol.org,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] CRED: Fix check_unsafe_exec()
Date: Tue, 10 Mar 2009 23:01:07 +0000 [thread overview]
Message-ID: <6503.1236726067@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0903102105590.21727@blonde.anvils>
Hugh Dickins <hugh@veritas.com> wrote:
> Surely we'd prefer to avoid the overhead of additional confusing
> counts if they can be avoided?
As long as they are properly commented, it shouldn't be too confusing.
> We already have what I think is a satisfactory patch for the struct fs
> part of it:
We do?
> /proc can easily manage root and pwd while holding the lock
> instead of raising fs->count.
I'm assume you mean by extending the time we hold task->alloc_lock until we've
completed the path_get().
> I don't understand why check_unsafe_exec() needs to check
> current->files->count at all, since do_execve() has already
> done an unshare_files() to get its own copy - and proceeds with
> that one if the exec succeeds.
>
> My belief is that the files->count check could/should have been
> removed when that unshare_files() was put in. Please explain why
> I'm wrong on that - I can quite accept that I'm muddled about it,
> but please do explain it to me.
It seems you're right about that. I think someone else on the security list
probably needs to answer that.
David
next prev parent reply other threads:[~2009-03-10 23:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-10 18:07 [PATCH] CRED: Fix check_unsafe_exec() David Howells
2009-03-10 21:31 ` Hugh Dickins
2009-03-10 23:01 ` David Howells [this message]
2009-03-10 23:40 ` Hugh Dickins
2009-03-12 13:23 ` David Howells
2009-03-16 22:15 ` Hugh Dickins
[not found] <3830454.11106421237315019351.JavaMail.root@ouachita>
2009-03-17 18:39 ` Joe Malicki
2009-03-17 23:07 ` Joe Malicki
2009-03-19 18:44 ` Hugh Dickins
[not found] <1906769.11304931237505721331.JavaMail.root@ouachita>
2009-03-19 23:36 ` Joe Malicki
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=6503.1236726067@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=chrisw@sous-sol.org \
--cc=hugh@veritas.com \
--cc=jmalicki@metacarta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.