Q:

Is this design over-engineering?

Would you consider using an interface and polymorphism to extend this design to be over-engineering?
Pros

Extensible
Encapsulated
Auto-magical

Cons

Lots more code
A little bulky to use (you have to use a different type name to get the different behaviour)
May be less efficient to use due to virtual function calls.

My instinct is that, for this particular case, a single if statement and a boolean flag is the superior option, but not everybody has agreed with me.
What do you think?

Original
// Connects to a local pipe, and naturally
// owns that connection
struct CommandWriter
{
   CommandWriter() {
       fd = open("/path/to/fifo", O_WRONLY);
       if (fd == -1)
           throw std::runtime_error("Could not establish connection to FIFO");
   };

   ~CommandWriter() {
       close(fd);
   };

   // (Has useful member functions here)

   private:
      CommandWriter(CommandWriter const&); // Not relevant to question

      int fd;
};

Extended with a boolean flag
// Adds a constructor where an FD can be specified
// from the call site, and no ownership is taken
struct CommandWriter
{
   CommandWriter() : owns_fd(true) {
       fd = open("/path/to/fifo", O_WRONLY);
       if (fd == -1)
           throw std::runtime_error("Could not establish connection to FIFO");
   };

   CommandWriter(int fd) : fd(fd), owns_fd(false) {};

   ~CommandWriter() {
       if (owns_fd)
          close(fd);
   };

   // (Has useful member functions here)

   private:
      CommandWriter(CommandWriter const&); // Not relevant to question

      int  fd;
      bool owns_fd;
};

Extended with polymorphism
// Sorry for the poor type names!
struct ICommandWriter
{
   virtual ICommandWriter() {}

   // (Has useful member functions here)

   private:
      ICommandWriter(ICommandWriter const&); // Not relevant to question
};

struct CommandWriter_Connects : ICommandWriter
{
   CommandWriter_Connects() {
       fd = open("/path/to/fifo", O_WRONLY);
       if (fd == -1)
           throw std::runtime_error("Could not establish connection to FIFO");
   };

   ~CommandWriter_Connects() {
       close(fd);
   };

   // (Has useful member functions here)

   private:
      int fd;
};

struct CommandWriter_Uses : ICommandWriter
{
   CommandWriter_Uses(int fd) : fd(fd) {};

   ~CommandWriter_Uses() {};

   // (Has useful member functions here)

   private:
      int fd;
};

A:

It depends on what you will use it for.  If you have a big project and will use variants of the class many times then certainly it makes sense to make it flexible.  
A rule of thumb:

Use it once - just keep it simple.
Use it twice - Keep it simple and make a copy and change as needed
Three or more - Generalise it and make it work for all cases.

Of course there are many exceptions, but that is a starting point.

A:

Why don't you just duplicate file descriptor? That way, when object is destroyed, you can just close() it and let the operating system take care of the rest:
CommandWriter::CommandWriter (int _fd) : fd (dup (_fd)) {};

Adding a boolean flag for this is inventing a wheel. And using polymorphism is building a frigging helicopter.

