2) a way for community user to update contact's field without 'Read' permission on Contact.
Create a custom object that they have read and write permissions to that has the same fields in that Contact does which you want your portal users to update. You can then use an After Update trigger to update Contacts whenever a Portal User updates their information to the custom object.
You'll want 2 triggers. One that syncs After Insert and After Update from Contacts to the Custom Object and another that syncs After Update (You may want After Insert too, depending on how you configure things) from the Custom Object back to Contacts.
Record ownership, sharing and field level security are also important aspects you need to address which I didn't discuss. In a community they can be handled in a number of ways, in fact too many ways for me to cover here. In this case, on the Custom Object, the sharing model would be set to Private. The portal user would have read/write access to the Object, but would only have read/write access to the records they actually own. All other records which they don't would be hidden. In this manner, other records shouldn't be visible to them in a Global Search. At a minimum, they wouldn't be able to see the fields they don't have at least read-only access to. Remove read-only access to the "Name" field, and they won't see that either.
This may be the source of your issue with Contacts. Typically a a contact record has an owner other than the person who's the contact. You didn't say what type of community user license you're using, but what we did in a similar situation was set up sharing so that a Portal User could edit certain types of records (like their contact info) by setting up a sharing model where the Owner of the Contact shared edit-only privileges with the record with the Portal User.
I didn't set up the details of that sharing model, so can't tell you exactly how it was done. I know that any records created by the portal users (this was a high volume customer portal/community) were actually owned by the Portal User's contact owner. That wasn't the way we originally architected the community security model, but its how it was configured when it went into production as things changed between the time communities were made available and the time we finished the project, plus we learned a lot along the way.
So, in general here, I think the issue for you is that you want to make certain your Portal Users don't have records shared with them which they can't edit or don't need to see. If you do that, even if they come up in a global search, they won't be able to view them.