Message-ID: <AANLkTim-GJ9ObZ19jriNvAxMYNZ2JdKGxVRVE53emNvr@mail.gmail.com>
Date:	Tue, 29 Jun 2010 15:23:21 -0700
From:	Lei Sun <leisun124@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	trond.myklebust@....uio.no
Subject: Fwd: fs/exec.c core dumping on NFS mounted directory

>>>>>>
>>>>>> The fixing of Bug-3043 clearly broke the logic of dumping core on NFS
>>>>>> mounted file system with different UID.
>>>>>> If my patch is not accepted. I am hopping the bug-3043 to be
>>>>>> re-opened. and to be fixed
>>>>>
>>>>> Using different uids on the client and server for NFSv2 and NFSv3 is a
>>>>> broken setup. Don't do it.
>>>>> The only way such a NFS client can be sure that the file was really
>>>>> created by itself would be to use an exclusive create. That would break
>>>>> if the file 'core' already exists, though.
>>>>>
>>>>> Can't you use NFSv4 instead? If set up correctly, that will allow you to
>>>>> use different uid and gid mappings on the client and server (provided
>>>>> that the user name and group names are the same).
>>>>>
>>>>>
>>>>>
>>>>>
>>>> NFS mount is just one problem out of other potential breaks. We are
>>>> working on embedded Linux and mount to company filer via NFS and
>>>> observed this issue. Even I could change the NFS server(Not to mention
>>>> that we have a big IT department handles it), other people could still
>>>> see the problems.
>>>>
>>>> The checking of "inode->i_uid != current_fsuid" could break in :
>>>>
>>>> 1) NFS mount using root_squash: if current_fsuid() == 0, inode->i_uid
>>>> will be nonzero.  Very common in embedded development.
>>>
>>> Definitely a case where you want to _disallow_ core dumping. The
>>> resulting core dump is owned by someone other than the process that
>>> created it.
>>>
>>>> 2) Writable VFAT mount (e.g. umask=0): current_fsuid() might not match
>>>> the filesystem ownership, so a process that has permission to write to a
>>>> directory still can't dump core there.  On embedded platforms the VFAT
>>>> filesystem is likely to reside on an SDHC/eMMC card, USB flash drive,
>>>> external HDD, etc.
>>>
>>> Ditto.
>>>
>>>> 3) Host is using 32-bit UIDs, but the filesystem can only handle 16-bit
>>>> UIDs.  current_fsuid() may not match inode->i_uid in the case of overflow.
>>>
>>> Ditto.
>>>
>>>
>>
>> I really don't understand in all above 3 case, why am I not allowed to
>> dumping core...
>> Taking NFS mount as an example.
>> Yes, the process will dump out core file owned by other user. So will
>> be the "copy file over to NFS directory. Should it disallow copying
>> local file to NFS directory as well? if the NFS doesn't preserve the
>> original UID/GID?
>>
>> So you are saying, it is not a bug, it is expected behavour, e.g. I
>> can't dump core on above 3 cases?
>
> Yes
>
>> Although I don't see any security
>> threat of dumping core on NFS/USB and owned by other user.
>
> The security threat lies in the fact that core files are a memory dump. They can contain all sorts of information, such as passwords, ssl session data, ssh keys, private emails, etc. Stuff that you might not want to expose to other people.
>
> Trond

I understand the security concern. The original fix was for general cases.
What I am asking is "is it legitimate thing to do for a root user
process to dump core file on NFS directory?", there are two cases:

1. The NFS server doesn't change the UID/GID, in this case, the
current kernel allow dumping core over NFS.
2. The NFS server does change UID/GID, in this case the current kernel
doesn't allow core dumping.

So current kernel didn't answer the question, because it behave
differently based on different NFS server setting.  Vital information
is not protected for case #1, isn't it?

Hi Trond:
   Any more comments on the question above?

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists