I agree with many of the points made in the other answers, but I'd have phrased it differently, so I'll submit a different answer.

First, both read and write access to the component as a whole is determined by what you specify as the "owner" of that component.   As part of the ownership specification, you can include description of the visibility (e.g. if a user owns the component, is it private visibility where only the user can see it, or is it public visibility where everyone can see it).   But it is best to think of visibility as part of ownership, because only by modifying the ownership will you be given the opportunity to adjust the visibility.

Second, read access to a component is handled differently from write access.   In particular, read access to the component controls both to the metadata of a component (e.g. the component name) as well as to the content of a component (e.g. the change sets, and file content of those change sets).  In addition, you can define fine-grained read-access at the individual file or folder level.   So to have read access to a particular file or folder, you need both read access to the component containing that file/folder, and read access to that particular file/folder.

On the other hand, write access to the component as a whole *only* constrains write access to the metadata of the component.   It does *not* constrain write access to the data of the component ... in particular, anyone that has read access to a component can create new change sets in that component (for both new and existing files/folders in that component).   This is a very deliberate design choice ... anyone who has read permission to a component can make a copy of that data outside of RTC and then change that copy ... so all that you would achieve by limiting who can create change sets in a component is forcing those users to work outside of the SCM system.  So what RTC does let you control is whether a change set can be added to a stream or workspace (i.e. who can change a stream or workspace).   But this isn't write permission to the component, but rather is "component-scoped write permission to the stream/workspace".  

So in summary, when you want to specify read-access to component data, you can do that to the component as a whole via the ownership of the component, or in a fine-grained way via access control on individual files and folders.  And when you want to specify component-scoped write access to files in a given stream, you would do so by adjusting the write access for that stream.

Hi Daniel,
a component has two parts: the ownership and visibility.
Ownership of a component is only for editing the meta data of the component like changing the name and changing the visibility / owner itself. So its just partly interesting.

For the ownership you have two options. Who can be owner of a component?
- a whole team
- a single person

In addition to this you can set the visibility either for public (everybody), a whole project area or the owner (means team private or personal private).

This means for visibility (reading) you can only set the owner (team or person) or everybody/project area

Writing is another part to think about.
Write access is managed through the stream. Only the one who has write permission to the stream is able to write to the component.
The write permission is managed through the ownership of a stream. A stream can only belong to a team or a whole project area.

Means to answer your question:
If you want to have a component which is only writeable to a small set of ppl you have to create a new team where the stream and component belongs to. This team is only able to write within this component.

Hope this helps,
Greetings,
Simon

You can create a team area for the people who you want to work on this component then set the owner of the component to this newly created team area. Form that point on, only the new team member and its sub-team members can to make changes to this component.