SQL - PostgreSQL - SET search_path = ''를 사용하는 이유?

PostgreSQL

 

 

✅ SET search_path = ''를 사용하는 이유?

---

CREATE FUNCTION public.notify_follow()
RETURNS TRIGGER
SECURITY DEFINER SET search_path = ''
LANGUAGE plpgsql
AS $$
BEGIN
    INSERT INTO public.notifications (type, source_id, target_id)
    VALUES ('follow', NEW.follower_id, NEW.following_id);
    RETURN NEW;
END;
$$;

CREATE TRIGGER notify_follow_trigger
AFTER INSERT ON public.follows
FOR EACH ROW
EXECUTE FUNCTION public.notify_follow();

우선 SECURITY DEFINER를 작성한 이유는 뭘까?

INSERT INTO notifications 권한을 사용자에게 주고 싶지 않기 때문이다.

사용자가 가짜 notifications을 생성할 수 있기 때문이다.

 

하지만 Trigger가 생성하는 notifications는 허용하고 싶다.

그렇기 때문에 SECURITY DEFINER를 사용해서

Trigger 함수 안에서만 Owner 권한으로 notifications에 INSERT 하도록 만든 것이다.

 

그렇다면 SET search_path = ''은 왜 필요한걸까?

SECURITY DEFINER를 사용하면 보안 취약점이 생길 수 있기 때문에, 그 취약점을 막기 위해 SET search_path = ''를 함께 사용하는 것이다.

 

이게 무슨 말이냐면

CREATE FUNCTION track_event(...)
LANGUAGE plpgsql;

만약 이런 FUNCTION이 있을 때 이 FUNCTION은 기본적으로 SECURITY가 INVOKER다.

사용자 권한으로 실행된다는 뜻이다.

 

그래서

INSERT INTO events ...

가 잘못된 테이블을 참조하더라도

피해는 사용자가 원래 가지고 있는 권한 범위 안에서만 발생한다.

즉 큰 보안 문제가 되지는 않는다.

 

하지만

CREATE FUNCTION ...
SECURITY DEFINER

가 되면 Owner(postgres)권한으로 실행된다.

 

이 상태에서

UPDATE posts

처럼 schema를 생략하면

PostgreSQL은 search_path를 따라가면서 posts를 찾게 된다.

 

만약 악의적으로 다른 schema에 posts나 some_function() 만들어 놓고

search_path를 이용하도록 유도하면

Owner 권한으로 그 객체를 실행하는 보안 문제가 발생할 수 있다.

 

그래서

SECURITY DEFINER
SET search_path = ''

이 두 개를 같이 사용한다.

그러면 자동으로 schema를 찾지 않는다.

 

즉

UPDATE posts

는 실패하고

 

반드시

UPDATE public.posts

처럼 schema를 명시해야 한다.

 

✅ 결론

---

SECURITY DEFINER
        ↓
Owner 권한으로 실행
        ↓
search_path 악용 가능성 발생
        ↓
SET search_path = ''로 방지