My first instinct is to go for a “has a” relationship on both ends. I can easily imagine a situation where grabbable objects are otherwise completely different actors with different purposes and behaviours, so going with the “is a”/inheritance route could end up with having to copy code or pile it up in the class on the top of the hierarchy.
The use of a component on the “grabber” end is probably less important, but some kind of component will be very handy for defining where exactly will the grabbable objects attach to the player pawn anyway, so why not make it as self contained as possible.
As far as my knowledge of UE4 goes, the act of grabbing itself should be simple to do; just disable physics on the grabbable object, interpolate it’s location to the players’ grabber component, and attach the object to it. Detach and reenable physics on release.
However, detecting the grabbable object in a suitable way could prove to be more difficult in an FPP game. A simple collision check around the player would be sufficient only in a situation where only one grabbable object is available to the player in a given area; if that is not the case, a procedure that decides which object that passes the collision check is closer to the centre of the screen should be implemented(a binary “hotzone” or pointing mechanic tends to feel stiff in my opinion). Some proper feedback on the HUD - like, for example, outlining the currently grabbable object - could prove crucial, as well.