N

Для поиска самих link_id

select link_id from tablename
group by link_id
having count(*) = sum(flag  = 1)

Либо

select id from links
where exists(select null from tablename where flag  = 1 and link_id = links.id) -- возможно это условие вам по задаче не нужно
and not exists(select null from tablename where flag != 1 and link_id = links.id)

Вычитывать сами строки можно попробовать через

select ...
from tablename t
where t.flag = 1
and not exists(select null from tablename sq where sq.link_id = t.link_id and sq.flag != 1)

При том, какой из вариантов эффективнее - критично зависит от распределения данных. При большой числе различающихся link_id с малым числом строк на каждый link_id и малым ожидаемом числе подходящих строк под задачу может быть эффективнее именно

select ... from tablename t where t.link_id in (
select q.link_id from tablename q
group by q.link_id
having count(*) = sum(flag  = 1)
)

При большом числе строк на каждый link_id и малом числе разных link_id может оказаться разумнее аналогично сначала достать link_id удовлетворяющие условию и по ним уже доставать данные.

Третий запрос по ожиданию лучше отзовётся на случай малого числа flag = 1 строк в таблице.

Самый быстрый на чтение вариант, впрочем, всё равно не выполнять обработку этого фильтра налету, а каким-то образом его материализовать и хранить предварительно рассчитанным.

например так:

SELECT t.*
FROM my_table t
WHERE NOT EXISTS(
  SELECT null FROM my_table t2 WHERE t2.link_id = t.link_id and t2.flag=0
)

Можно и с джойном:

WITH tt AS(SELECT DISTINCT link_id WHERE flag = 0)
SELECT t1.*
FROM
    my_table t1
    LEFT JOIN tt t2 ON t2.link_id = t.1link_id
WHERE t2.link_id is None

Вариант 1.

Верстальщику проще сверстать чистый html-код, чем потом разбираться в коде backend-разработчика. Не говоря о наличии сложных ветвлений, которое добавит путаницы и может привести к упущению некоторых веток

> Как работает параметр user при запуске докер-контейнеров и, самое главное - как обрабатывать его при написании своих Dockerfile'ов?

никак. Параметр user это костыль, который позволяет софт запускать не от root'ового пользователя. Объяснять почему запускать в докере под пользователем 0 (root) что-либо - долго, но если кратко, то это очень плохо и не секурно. Соответственно, правильный путь Вы уже поняли:

1. определять entrypoint контейнера как свой самописанный docker-entrypoint.sh скрипт
   
2. в docker run оставить возможность передать ключ (точнее - переменную среды) USER
   
3. в docker-entrypoint.sh его (ее, переменную среды) подхватывать и изменять через chmod/chown нужные файлы в bind-mount (каталогах, доступных и в контейнере, и на хосте) и через утилиту gosu переключаться в нужного пользователя
   
4. и только как завершающий этап - запускать свой сервис в докере
   

Что еще добавить. Все эти проблемы с chown/chmod возникают только если необходимо перегонять файлы между контейнером и хостом. Если этой задачи не стоит, то и все приседания и не нужны. А если все-таки нужно, то есть еще два способа это сделать без колдования с правами:

• команда docker cp
  
• использование pipe: docker exec container_name cat MY_FILE > path_on_host или аналогично
  

Подведу итог для ищущих ответ:
Laravel, Lumen, Slim, Silex и т.д. - фраемворки для разработки сайтов. Побочно на них можно реализовывать API.
Если нужен голый роутинг - Slim
Если нужны плюшки - Lumen

Laravel для API излишен однозначно.