첫째 : Boost.Interprocess에서 제공
명명 된 자원도 존재하는 파일을 작성하는 플랫폼 의존의 권한 문제에 대처해야합니다. 프로그래머가 공유 메모리, 메모리 매핑 파일 또는 이름 동기화 메커니즘 (뮤텍스, 세마포어 등)을 사용자간에 공유하려는 경우 이러한 권한을 지정해야합니다. 유감스럽게도 전통적인 UNIX와 Windows 사용 권한은 매우 다르며 Boost.Interprocess는 사용 권한을 표준화하려고하지는 않지만 무시하지는 않습니다.
모든 명명 된 리소스 생성 함수는 플랫폼 종속 사용 권한으로 구성 할 수있는 선택적 사용 권한 개체를 사용합니다. 각 메커니즘은 서로 다른 메커니즘을 통해 에뮬레이트 할 수 있기 때문에 (세마포어 수도있을 매핑 된 파일을 사용하여 구현하거나
: 당신이 그렇게 할 경우
후 즉시 특정 플랫폼에 필요한 permissiong에 대해 알고 있고, 조심 네이티브 세마포어) 사용 권한 유형은 명명 된 리소스의 구현이 변경 될 때 달라질 수 있습니다 (예 : Windows 뮤텍스에서 동기화 사용 권한이 필요하지만 파일의 경우는 아닙니다). 이 문제를 피하기 위해 Boost.Interprocess는 [보통 ¹, 빨간색]과 같이 이름이 지정된 동기화 메커니즘 (뮤텍스, 세마포어 등) 및 적절한 읽기 또는 읽기를 열기 위해 파일 읽기 - 쓰기 - 삭제 권한이 필요합니다 공유 메모리에 대한 쓰기 권한을 삭제합니다. 이 접근 방식은 두 가지 장점이 있습니다. UNIX 유 틸리 티와 유사하며 프로그래머는 명명 된 리소스가 어떻게 구현되는지 알 필요가 없습니다.
사용 권한을 통과 하지 개체 때 ¹
당신의 다른 질문 :
- 는 (? 예, 아마 창에
AdjustTokenPrivileges 사용)로 시작 할 권한이 없지만,
- 은 공유 메모리 매핑 된 파일에 대한 읽기 권한이 부여됩니다 (예 : s를 구성 할 때 사용 권한 설정). hared 메모리 세그먼트 α)
permissions 객체 않는
번호되지는 호출 프로세스 권한을 준다. permissions 개체 은 다른 프로세스에 대해 액세스를 제한합니다. 나는 create_only 또는 open_or_create에 permissions을 지정하는 것이 의미가 있다고합니다.
Windows에서 액세스 제어 목록 d this) : 액세스 할 수있는 추가/다른 계정을 지정할 수 있어야합니다.
리눅스에서 이러한 제어를 달성하려면 추가 시스템 호출이 필요합니다 (예 : 공유 객체의 소유자/그룹을 변경하거나 클라이언트 사용자 계정을 기본/보조 그룹으로 추가하는 경우)).
요약 : _I는 "사용 권한없이받는 사람 시작"대신 특정받는 사람에게 액세스 권한을 부여하는 데 중점을 둡니다. 후자는 비실용적입니다 (프로세스가 "권한없이"기능하지 않을 수도 있음). 런타임 중에 권한을 높이는 것은 정적으로 할당/관리 된 권한을 사용하는 것보다 훨씬 어렵습니다. 물론 본질적으로 사용 권한을 추가하는 것이 덜 안전합니다.
이것은 도움이됩니다. 진정한 도전은 각 플랫폼의 사용 권한을 이해하는 것입니다. – wally
나는 그 평가에 완전히 동의한다. – sehe