From: Steve Dickson <SteveD@redhat.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 1/1] mount.nfs: mtab corruption when RLIMIT_FSIZE causes a partial write
Date: Wed, 19 Oct 2011 13:30:58 -0400 [thread overview]
Message-ID: <4E9F0952.2040607@RedHat.com> (raw)
In-Reply-To: <20111019132230.6cd85a0c@corrin.poochiereds.net>
On 10/19/2011 01:22 PM, Jeff Layton wrote:
> On Wed, 19 Oct 2011 13:10:19 -0400
> Steve Dickson <SteveD@redhat.com> wrote:
>
>>
>>
>> On 10/19/2011 12:36 PM, Jeff Layton wrote:
>>> On Wed, 19 Oct 2011 11:34:30 -0400
>>> Steve Dickson <steved@redhat.com> wrote:
>>>
>>>> This patch is a following on to commit 7a802337. Using the
>>>> tool in https://bugzilla.redhat.com/show_bug.cgi?id=695916
>>>> caused the fflush() and fclose() to fail in turn causing
>>>> corruption in the mtab.
>>>>
>>>> The failures were in the internals of both calls. Switch those
>>>> calls with the actual system calls eliminated the failures.
>>>>
>>>> Signed-off-by: Steve Dickson <steved@redhat.com>
>>>> ---
>>>> support/nfs/nfs_mntent.c | 4 ++--
>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/support/nfs/nfs_mntent.c b/support/nfs/nfs_mntent.c
>>>> index a2118a2..b80f270 100644
>>>> --- a/support/nfs/nfs_mntent.c
>>>> +++ b/support/nfs/nfs_mntent.c
>>>> @@ -117,7 +117,7 @@ void
>>>> nfs_endmntent (mntFILE *mfp) {
>>>> if (mfp) {
>>>> if (mfp->mntent_fp)
>>>> - fclose(mfp->mntent_fp);
>>>> + close(fileno(mfp->mntent_fp));
>>>> if (mfp->mntent_file)
>>>> free(mfp->mntent_file);
>>>> free(mfp);
>>>> @@ -147,7 +147,7 @@ nfs_addmntent (mntFILE *mfp, struct mntent *mnt) {
>>>> free(m3);
>>>> free(m4);
>>>> if (res >= 0) {
>>>> - res = fflush(mfp->mntent_fp);
>>>> + res = fsync(fileno(mfp->mntent_fp));
>>>
>>> fsync doesn't imply an fflush. With this, I think you may end up
>>> without everything being committed to disk if part or all of it is
>>> still in the file stream buffer. You probably want to do an fflush()
>>> and then an fsync here.
>> The problem was with the fflush() call. The call was causing the
>> mount to drop core in turn causing mtab corruption. Changing that
>> call to a fsync() worked just fine... no corruption... every time!
>>
>
> Ahh, then you have another problem here too then. Most likely it was
> crashing because it caught a SIGXFSZ. Writing out the mtab should not
> be affected by signals.
So calling fflush() generates a SIGXFSZ and call fsync() does not...
I really don't see what the problem is is call simply calling fsync()
which clearly works?
steved.
>
> In the mount.cifs helper, I have it do the following before altering
> the mtab (with appropriate error handling):
>
> rc = setreuid(geteuid(), -1);
> rc = sigfillset(&mask);
> rc = sigprocmask(SIG_SETMASK, &mask, &oldmask);
>
>
> IOW, set the real uid to the effective UID to ensure that an
> unprivileged user can't signal the process if it was run as a setuid
> root program and the real UID isn't root. It then masks off all
> signals. That leaves SIGKILL by root as a way to interrupt it but
> there's really nothing you can do about that.
>
>>
>>>
>>>> if (res < 0)
>>>> /* Avoid leaving a corrupt mtab file */
>>>> ftruncate(fileno(mfp->mntent_fp), length);
>>>
>>>
>
>
next prev parent reply other threads:[~2011-10-19 17:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 15:34 [PATCH 1/1] mount.nfs: mtab corruption when RLIMIT_FSIZE causes a partial write Steve Dickson
2011-10-19 16:36 ` Jeff Layton
2011-10-19 17:10 ` Steve Dickson
2011-10-19 17:22 ` Jeff Layton
2011-10-19 17:30 ` Steve Dickson [this message]
2011-10-19 17:36 ` J. Bruce Fields
2011-10-19 18:38 ` Steve Dickson
2011-10-19 19:55 ` J. Bruce Fields
2011-10-19 20:00 ` Steve Dickson
2011-10-19 20:01 ` J. Bruce Fields
2011-10-19 17:40 ` Jeff Layton
2011-10-19 18:00 ` Steve Dickson
2011-10-19 17:28 ` J. Bruce Fields
2011-10-19 17:32 ` Steve Dickson
2011-10-19 17:39 ` J. Bruce Fields
2011-10-19 19:44 ` Steve Dickson
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=4E9F0952.2040607@RedHat.com \
--to=steved@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@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.