KR100604241B1 - 멀티-프로토콜 파일 서버의 파일 액세스 제어 - Google Patents

멀티-프로토콜 파일 서버의 파일 액세스 제어 Download PDF

Info

Publication number
KR100604241B1
KR100604241B1 KR1019990037448A KR19990037448A KR100604241B1 KR 100604241 B1 KR100604241 B1 KR 100604241B1 KR 1019990037448 A KR1019990037448 A KR 1019990037448A KR 19990037448 A KR19990037448 A KR 19990037448A KR 100604241 B1 KR100604241 B1 KR 100604241B1
Authority
KR
South Korea
Prior art keywords
file
file server
access control
security
unix
Prior art date
Application number
KR1019990037448A
Other languages
English (en)
Other versions
KR20010026229A (ko
Inventor
히츠데이비드
보르안드레아
하윌리로버트제이.
뮤흘레스테인마크
피어슨조안
Original Assignee
네트워크 어플라이언스 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 네트워크 어플라이언스 인코포레이티드 filed Critical 네트워크 어플라이언스 인코포레이티드
Priority to KR1019990037448A priority Critical patent/KR100604241B1/ko
Publication of KR20010026229A publication Critical patent/KR20010026229A/ko
Application granted granted Critical
Publication of KR100604241B1 publication Critical patent/KR100604241B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/606Protecting data by securing the transmission between two devices or processes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163Interprocessor communication

Abstract

본 발명은 다중의 다양한 액세스 제어 모델 및 다중의 다양한 파일 서버 프로토콜을 사용하여 클라이언트 장치 사이의 파일 액세스 제어를 실행하는 방법 및 시스템을 제공한다. 다중 프로토콜 파일 서버는 복수의 가능한 모델중의 하나의 특별한 액세스 제어 모델로 각 파일을 확인하고, 그 파일에 대한 모든 액세스를 위해 하나의 특별한 모델을 실행한다. 파일 서버가 다른 액세스 제어 모델을 사용하는 파일에 대한 파일 서버 요구를 수신할 때, 파일 서버는 파일에 대한 액세스 제어 제한을 다른 모델과 상응하는 제한적인 제한으로 변환한다. 파일 서버는 변환된 액세스 제어 제한을 사용하는 클라이언트 장치에 의해 액세스를 제한한다. 파일을 생성하거나 파일에 대한 액세스 제어 제한을 최후에 설정하는 유저의 액세스 제어 모델로 각 파일이 할당된다. 다른 액세스 제어 모델을 갖는 유저가 액세스 제어 제한을 설정할 때, 파일에 대한 액세스 제어 모델이 새로운 모델로 변화된다. 파일은 트리 조직으로 조직화되어, 각 트리는 1개 이상의 액세스 제어 모델로 제한된다(트리에서의 파일에 대한 액세스 제어 제한을 설정하는 유저의 능력을 제한할 수 있음). 각 트리는 NT-model-only 포맷, Unix-model-only 포맷, 또는 혼합된 NT-or-Unix-model 포맷으로 제한될 수 있다.

Description

멀티-프로토콜 파일 서버의 파일 액세스 제어{FILE ACCESS CONTROL IN A MULTI-PROTOCOL FILE SERVER}
도 1은 클라이언트 장치들 사이의 다양한 액세스 제어 모델을 실행하기 위한 시스템의 블록도이다.
본 발명은 멀티-프로토콜 파일 서버의 파일 액세스 제어에 관한 것이다.
집적화된 컴퓨터 네트워크에서, 다중 클라이언트 장치는 동일한 파일에 대해 액세스를 공유하는 것이 바람직하다. 하나의 공지의 방법은 클라이언트 장치로부터 파일 서버 요구에 수신 및 응답할 수 있는, 파일을 기억하기 위한 네트워크 파일 서버를 제공하는 것이다. 파일 서버 및 클라이언트 장치 모두에 의해 인식 및 부착된, 파일 서버 프로토콜을 사용하여 이들 파일 서버 요구가 생성된다. 파일이 파일 서버에 기억되기 때문에, 다중 클라이언트 장치는 동일한 파일에 대해 액세스를 공유할 기회를 갖는다.
1개 이상의 유저에 의해 사용되는 파일 시스템에서, 파일 시스템의 파일에 대해 프로그램에 의해 액세스를 제한하는 것이 바람직하다. 액세스의 제한은 적어 도 (1) 유저 확인 - 존재하는 실제적인 유저를 요구하는 결정, 및 (2) 액세스 제어 확인 - 특별한 방식으로 특별한 파일을 액세스하도록 허용되는 확인된 유저를 결정하는 관점을 포함한다. 파일 시스템이 요구를 생성하는 유저로부터 파일 서버 원격으로 유지될 때, 요구가 파일을 액세스하거나 파일에 대한 액세스 제어를 설정하는 유저에 의해 생성될 수 있는 것은 액세스 제어 프로토콜의 부가적인 관점이다.
공지 기술의 하나의 문제점은 통상 특별한 파일 시스템과 각각 결합된, 액세스 제어 확인에 대한 다중의 다양한 모델과, 통상 액세스 제어 확인에 대한 모델에 각각 대응하는, 다중의 다양한 액세스 제어 프로토콜이다. 이들 모델과 프로토콜 사이의 차이에도 불구하고, 파일 서버는 각 유저로부터의 파일 서버 요구에 응답해야 하고, 각 유저의 모델과 일관되고 보안 위반 또는 유저에 대한 경악이 없는, 액세스 제어 확인 행위를 나타내야 한다.
예컨대, 공통적으로 사용되는 제 1 액세스 제어 모델은 유닉스 운영 시스템(또는 그의 변형)과 결합된다. 이 제 1 액세스 제어 모델은 파일 오너, 오너의 그룹, 및 모든 다른 유저에 대한 각 파일과 허가를 결합시킨다. 이들 허가는 지시된 파일을 독출, 기입, 또는 실행하기 위한 액세스(오너, 그룹, 또는 모든 다른 유저에 대하여)를 허용한다. 보조 파일 락킹 프로토콜, NLM("네트워크 락 처리기")으로 가능한 증가된, NFS("네트워크 파일 시스템") 파일 서버 프로토콜에 의해 제 1 액세스 제어 모델이 통상 실행된다. 공통적으로 사용되는 제 2 액세스 제어 모델은 윈도우 NT 운영 시스템과 결합된다. 이 제 2 액세스 제어 모델은 개별적인 유저를 분류하는 ACL에서의 각 파일, 각 엔트리, 유저의 그룹, 또는 모든 유저와 ACL(액세 스 제어 목록)을 결합시킨다. 각 엔트리는 지시된 파일을 독출, 기입, 또는 실행하기 위한 액세스를 허용할 수 있거나, 명확하게 액세스를 부정할 수 있다. 이 제 2 액세스 제어 모델은 통상 CIFS("공통 인터넷 파일 시스템") 프로토콜에 의해 실행된다. 그러나, NT 장치도 "PC NFS" 실행에 의해 NFS 프로토콜을 사용할 수 있고, 유닉스 장치도 POSIX ACL을 다룰 수 있다. 공통적으로 사용되는 이들 2개의 액세스 제어 모델은 (1) 허가들이 파일로 할당될 수 있는 것, (2) 특이한 허가들의 세분성이 할당될 수 있는 것, 및 (3) 유저가 허가와 조화되도록 확인되는 방법을 포함하는, 중요한 방식에서 다르다.
상기 기술의 공지의 하나의 방법은 파일 서버에 대한 단일 원시 운영 시스템으로 모든 보안 의미를 맵하고, 파일 액세스 제어를 확인하기 위한 단일 원시 운영 시스템을 사용하는 멀티-프로토콜 파일 서버를 제공하는 것이다. "Samba" 시스템 및 유사한 모방 패키지들이 이 공지의 방법을 사용하리라고 생각된다. 이 공지의 방법은 파일 서버의 원시 운영 시스템과는 다른 보안 의미들을 사용하는 클라이언트 장치에 대한 보안 에러 또는 경악을 초래할 수 있는 단점을 갖는다.
상기 기술의 공지의 다른 방법은 다른 파일에 대한 보안 의미들의 다른 유형을 지원하지만, 유저의 액세스 제어 모델을 사용하는 각 유저에 대한 파일 액세스 제어를 확인하도록 시도하는 멀티-프로토콜 파일 서버를 제공하는 것이다. 노벨사로부터 이용할 수 있는 어떤 "네트웨어" 제품이 이 공지의 방법을 사용하리라고 생각된다. 이 공지의 방법은 유저의 액세스 제어 모델이 타게트 파일과 결합된 바와는 다른 보안 의미들을 사용하는 클라이언트 장치에 대한 보안 에러 또는 경악을 초래하는, 파일에 대한 액세스 제어 모델 세트로부터 상당히 다를 수 있는 단점을 갖는다.
따라서, 다중의 다양한 액세스 제어 모델 및 다중의 다양한 파일 서버 프로토콜을 사용하는 클라이언트 장치들 사이의 파일 보안 의미들을 실행하는 방법 및 시스템을 제공하는 것이 바람직하다. 멀티-프로토콜 파일 서버가 복수의 가능한 액세스 제어 모델중 하나의 특별한 액세스 제어 모델로 각 파일을 확인하고, 파일에 모든 액세스를 위해 특별한 액세스 제어 모델을 실행하는 본 발명의 실시예로서 이 장점이 얻어진다. 다른 액세스 제어 모델로 파일 서버 프로토콜을 사용하는 파일에 대한 파일 서버 요구를 파일 서버가 수신할 때, 파일 서버는 파일의 액세스 제어 모델에 의해 부과된 액세스 제어 제한을 다른 액세스 제어 모델에서의 제한적인 액세스 제어 제한으로 변환한다. 파일 서버는 변환된 액세스 제어 제한을 사용하여 파일에 대한 액세스를 제한한다.
본 발명은 다중의 다양한 액세스 제어 모델 및 다중의 다양한 파일 서버 프로토콜을 사용하여 클라이언트 장치들 사이의 파일 액세스 제어를 실행하는 방법 및 시스템을 제공한다. 멀티-프로토콜 파일 서버는 복수의 가능한 모델중 하나의 특별한 액세스 제어 모델로 각 파일을 확인하고, 파일에 대한 모든 액세스를 위해 하나의 특별한 모델을 실행한다. 파일 서버가 다른 액세스 제어 모델을 사용하여 파일에 대한 파일 서버 요구를 수신할 때, 파일 서버는 파일에 대한 액세스 제어 제한을 다른 모델에서의 제한적인 제한으로 변환한다. 파일 서버는 변환된 액세스 제어 제한을 사용하여 클라이언트 장치에 의해 액세스를 제한한다.
바람직한 실시예에서, 각 파일은 파일을 생성하거나 파일에 대한 액세스 제어 제한을 최후에 설정하는 유저의 액세스 제어 모델로 할당된다. 다른 액세스 제어 모델을 갖는 유저가 액세스 제어 제한을 설정할 때, 파일에 대한 액세스 제어 모델은 새로운 모델로 변화된다. 각 트리가 1개 이상의 액세스 제어 모델로 한정되는(트리에서 파일에 대한 액세스 제어 제한을 설정하기 위해 유저의 능력을 한정할 수 있는), 트리 조직에서 파일들이 조직화된다. 각 트리는 NT-model-only 포맷, Unix-model-only 포맷, 또는 혼합된 NT-or-Unix-model 포맷으로 한정될 수 있다.
다음 설명에서, 본 발명의 바람직한 실시예를 바람직한 프로세스 단계 및 데이터 구조에 대해 설명한다. 그러나, 본 출원의 추구 후에, 프로그램 제어하에서 동작하는 1개 이상의 일반적인 목적 프로세서(또는 특별한 프로세스 단계 및 데이터 구조로 채택된 특별한 목적 프로세서)를 사용하여 본 발명의 실시예가 실행되고, 이러한 장치를 사용하여 설명된 바람직한 프로세스 단계 및 데이터 구조의 실행이 부적당한 실험 또는 다른 발명을 요구하지 않음을 당업자들은 인식해야 한다.
이하에 설명된 본 발명은 다음 출원에서 설명된 발명과 관련하여 사용될 수 있다:
o 출원일련번호 08/985,398, 1997년 12월 5일에 제출됨, 안드레아 보르, "파일-락킹이 단일화된 멀티-프로토콜", 대리인 소송명부 번호 NET-023.
본 출원은 이하에 설정된 바와 같이 참조에 의해 결합된다.
동봉된 기술적인 부록은 본 발명의 공개부이고, 이하에 설정된 바와 같이 참조에 의해 결합된다.
시스템 소자들
도면은 클라이언트 장치들 사이의 다양한 액세스 제어 모델을 실행하기 위한 시스템의 블록도이다.
시스템(100)은 파일 서버(110), 및 클라이언트 장치(120)의 세트를 포함한다.
파일 서버(110)는 파일(112)의 세트를 포함하는, 파일 시스템(111)을 유지한다.
바람직한 실시예에서, 파일 서버(110)는 다음 특허출원에서 설명된 발명을 사용하여 파일 시스템(111)을 유지한다:
o 출원일련번호 08/471,218, 1995년 6월 5일에 제출됨, 데이비드 히츠 이티 에이엘., "비휘발성 메모리를 사용하는 레이드 서브-시스템에 패리티를 제공하는 방법", 대리인 소송명부 번호 NET-004;
o 출원일련번호 08/454,921, 1995년 5월 31일에 제출됨, 데이비드 히츠 이티 에이엘., "파일-시스템 레이아웃인 경우의 기입", 대리인 소송명부 번호 NET-005;
o 출원일련번호 08/464,591, 1995년 5월 31일에 제출됨, 데이비드 히츠 이티 에이엘., "레이드 디스크 서브-시스템으로 집적화된 파일 시스템에 파일을 할당하는 방법", 대리인 소송명부 번호 NET-006.
각각의 출원은 이하에 설정된 바와 같이 참조에 의해 결합된다.
클라이언트 장치(120)로부터 파일 서버 요구(121)를 수신하기 위해 파일 서버(110)가 배치된다. 파일 서버(110)는 각 요구(121)를 삭감하여, 요구(121)에 요 구되는 동작이 허용될 지를 결정한다(요구(121)를 전송하는 클라이언트 장치(120) 및 요구(121)에 의해 열거되는 1개 이상의 타게트 파일(112)에 관함). 허용되면, 1개 이상의 타게트 파일(112)에서 파일 서버(110)가 동작을 실행한다.
클라이언트 장치(120)에 파일 서버 응답(122)을 전송하기 위해 파일 서버(110)도 배치된다. 파일 서버(110)는 각 요구(121)에 대해 응답을 결정하며(요구된 동작이 허용되지 않도록 지시되는 응답을 포함), 응답(122)을 발생하고, 요구(121)를 전송하는 클라이언트 장치(120)에 응답(122)을 전송한다.
파일 서버(110)에 파일 서버 요구(121)를 전송하고, 파일 서버(110)로부터 파일 서버 응답(122)을 수신하기 위해 각 클라이언트 장치(120)가 배치된다.
액세스 제어 모델들
바람직한 실시예에서, 각 클라이언트 장치(120)는 유닉스 클라이언트 장치(120) 또는 윈도우 NT 클라이언트 장치(120)일 수 있다. 각 클라이언트 장치(120)는 요구(121)를 생산하기 위해 NFS 파일 서버 프로토콜을 사용하거나, 요구(121)를 생산하기 위해 CIFS 파일 서버 프로토콜을 사용할 수 있다.(전형적으로 유닉스 클라이언트 장치(120)는 NFS 파일 서버 프로토콜을 사용하고 NT 클라이언트 장치(120)는 CIFS 파일 서버 프로토콜을 사용하더라도, 파일 서버 프로토콜의 PC-NFS 실행을 사용함에 의해 NT 클라이언트 장치(120)가 NFS 파일 서버 프로토콜을 사용할 수 있다.) 파일 서버(110)는 각 요구(121)를 수신하고 (허용되면) 요구(121)에 의해 열거된 타게트 파일(112)에 요구된 동작을 실행한다.
"유닉스 펌" 액세스 제어 모델(이하 "유닉스 시큐리티 스타일") 및 "NT ACL" 액세스 제어 모델(이하 "NT 시큐리티 스타일")을 포함하는, 1개 이상의 액세스 제어 모델을 파일 서버(110)가 지원한다.
유닉스 시큐리티 스타일은 유저들을 확인하기 위해 유저 ID(UID), 및 그 유저들이 속한 그룹을 확인하기 위해 그룹 ID(GID)를 사용한다:
o 오너에 대한 UID
o 오너에 대한 GID
o "유저" 허가의 세트-소유 유저에 의해 파일을 독출, 기입, 실행하는 허가를 허용
o "그룹" 허가의 세트-소유 유저의 그룹에 의해 파일을 독출, 기입, 실행하는 허가를 허용
o "다른" 허가의 세트-모든 다른 유저에 의해 파일을 독출, 기입, 실행하는 허가를 허용
NLM("네트워크 락 처리기") 보조 파일-락킹 프로토콜에 의해 증가된, NFS("네트워크 파일 시스템") 파일 서버 프로토콜에 의해 유닉스 시큐리티 스타일이 지원된다.
NFS는 국적없는 프로토콜이어서, 각 NFS 파일 서버 요구(121)는 요구를 생산하는 유저의 UID 및 GID를 포함한다. 시스템 패스워드 파일(/etc/passwd) 및 그룹 파일(/etc/groups)에 대해 참조함에 의해, 유닉스 클라이언트 장치(120)는 유저에 대한 로그인 시간에서 유저에 대해 UID 및 GID를 결정한다.
유닉스 시큐리티 스타일을 사용하여 파일 액세스 제어를 실행하기 위해서, 요구(121)가 소유 유저, 소유 유저의 그룹의 유저, 또는 임의의 다른 유저로부터 인지를 파일 서버(110)가 결정한다. 이 결정에 응답하여, 요구(121)를 허용할 지를 결정하기 위해, 파일 서버(110)는 유저 허가, 그룹 허가, 또는 다른 허가중의 하나를 사용한다.
NT 시큐리티 스타일은 유저 및 그룹 양쪽을 확인하기 위해 보안 ID(SID)를 사용한다.
o 오너에 대한 SID
o 오너의 그룹에 대한 SID
o ACL(액세스 제어 목록)
NT ACL은 유저 또는 적용하는 그룹을 지시하는 SID, 및 허가의 세트를 각각 포함하는, 1개 이상의 ACE(액세스 제어 엔트리)를 포함한다. NT 시큐리티 스타일은 "CHANGE PERMISSIONS" 허가, "TAKE OWNERSHIP" 허가, "DELETE" 허가, "DELETE CHILD" 허가, 및 다른 허가 뿐만 아니라, 3개의 유닉스 허가(독출, 기입, 또는 실행)를 제공한다.
NT 시큐리티 스타일이 CIFS("공통 인터넷 파일 시스템") 프로토콜에 의해 지원된다. NT 시큐리티 스타일은 다음 항목으로 더 설명된다: 알. 레이첼, "내측 윈도우 NT 보안", 윈도우/DOS 개발자의 저널(1993년 4월 및 5월호), 및 스테픈 서튼, "윈도우 NT 보안 가이드"(ISBN 0201419696).
CIFS는 세션 베이스드 프로토콜이어서, 유저 및 유저의 그룹에 대한 SID가 결정되는 것으로부터, 세션 접속 시간에 파일 서버(110)에 NT 유저 이름 및 패스워 드를 NT 클라이언트 장치(120)가 전송한다. 파일 서버(110)는 유저 자체로 증명을 시도하거나, NT 주요 도메인 제어기에 NT 유저 이름 및 패스워드를 제시할 수 있다.
NT 시큐리티 스타일을 사용하여 파일 액세스 제어를 실행하기 위해서, 유저가 요구(121)를 생산하도록, 파일 서버(110)는 유저 및 유저의 그룹에 대한 SID를 결정한다. 파일 서버(110)는 적용하는 ACE로부터 유저에 주어지는 허가를 축적한 후, 특히 유저에 대해 부정된 허가를 공제한다. 이 축적 및 공제에 대응하여, 파일 서버(110)는 요구(121)를 허용할 지를 결정한다.
본 발명의 바람직한 실시예가 유닉스 시큐리티 스타일 및 NT 시큐리티 스타일에 대해 설명되더라도, 본 발명은 임의의 유닉스 장치, 및 임의의 다른 작동시스템에 의해 지원되는 "POSIX ACL" 액세스 제어 모델 등의, 다른 액세스 제어 모델이 사용될 수 있다. 다른 발명 또는 부적당한 실험 없이, 이하에 설명된 본 발명의 개념 및 특징은 "POSIX ACL" 액세스 제어 모델을 지원하는 파일 서버(110) 또는 상세하게 이하에 설명된 액세스 제어 모델 대신에 사용될 수 있다. 따라서, 본 발명의 범위 및 정신은 이러한 파일 서버 및 그의 사용방법을 포함한다.
파일 서버(110)는 그가 지원하는 복수의 액세스 제어 모델중의 하나의 구체적인 액세스 제어 모델을 갖도록 그의 파일 시스템(111)에 유지되는 각 파일(112)을 지적한다. 바람직한 실시예에서, 각 파일(112)은 유닉스 시큐리티 스타일 또는 NT 시큐리티 스타일을 사용하기 위해 지적된다. 파일 서버(110)는 지적된 시큐리티 스타일이 각 파일(112)에 대해 파일(112)을 액세스 하기 위한 모든 시도를 하게끔 한다. 따라서, 그 요구(121)가 유닉스 장치 또는 NT 장치로부터 인지, 및 그 요구(121)가 NFS 파일 서버 프로토콜 또는 CIFS 파일 서버 프로토콜을 사용하는 지를, 파일 서버(110)가 타게트 파일(112)에 대해 생산된 모든 요구(121)에 대해 지적된 시큐리티 스타일을 강요한다.
액세스 제어 실행
파일 서버(110)가 타게트 파일(112)에 대해 요구(121)를 수신하고, 요구(121)가 시큐리티 스타일 타게트 파일(112)과 부합하면, 파일 서버(110)는 시큐리티 스타일에 의해 강요된 파일(112)에 대한 액세스 제어 제한에 대해 요구(121)를 확인한다.
따라서, 파일 서버(110)는 적어도 다음 환경을 인식하고 실행한다:
o NT 시큐리티 스타일. 파일(112)은 NT 시큐리티 스타일을 갖고 CIFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)에 의해 설정되는, 액세스 제어 제한(NT ACL)의 대응하는 세트를 갖는다.
클라이언트 장치(120)가 CIFS 파일 서버 프로토콜을 사용하는 파일(112)을 액세스하도록 요구(121)를 생산하면, 파일 서버(110)는, 가능하면, NT 시큐리티 스타일을 사용하는 NT ACL을 실행한다.
파일 서버(110)가, NT 도메인 제어기와의 통신, 또는 NT 유저 SID(보안 ID) 데이터베이스에 대해 참조함에 의해 NT 유저를 결정할 수 있다면, 파일 서버(110)는 NT 시큐리티 스타일을 사용하는 NT ACL을 실행할 수 있다.
파일 서버(110)가 NT 유저를 결정할 수 없다면, CIFS 파일 서버 프로토콜 세 션에 기록된 유닉스 유저에 대한 UID를 사용하여, 동등한 유닉스 유저를 결정하고, 요구(121)가 유닉스 유저로부터 오는 것처럼 NT ACL을 실행한다.
o 유닉스 시큐리티 스타일. 파일(112)은 유닉스 시큐리티 스타일을 갖고 NFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)에 의해 설정되는, 액세스 제어 제한(유닉스 펌)의 대응하는 세트를 갖는다.
클라이언트 장치(120)가 NFS 파일 서버 프로토콜을 사용하는 파일(112)을 액세스하기 위해 요구(121)를 생산하면, 파일 서버(110)는 유닉스 시큐리티 스타일을 사용하는 유닉스 펌을 실행한다.
그러나, 파일 서버(110)는 타게트 파일(112)에 대한 시큐리티 스타일과 부합하지 않는 요구(121)도 수신할 수 있다. (1) 클라이언트 장치(120)에 대해 변환된 유저 ID 또는 (2) 파일(112)에 대해 액세스 제어 제한의 변환된 세트를 확인함에 의해 비부합 클라이언트 장치(120)에 대해 타게트 파일(112)에 대한 시큐리티 스타일을 파일 서버(120)가 실행할 수 있다. 여기에 설명된 바와 같이, 파일 서버(110)는 유닉스 시큐리티 스타일 파일(112)에 대해 변환된 유저 ID를 확인하고, 바람직하게는 NT 시큐리티 스타일 파일(112)에 대해 변환된 유저 ID를 확인한다(가능할 때). 또한, 파일 서버(110)가 파일(112)에 대해 변환된 액세스 제어 제한을 확인할 때, 변환된 액세스 제어 제한은 각 요구(121)에 대해 재계산되지 않으나, 재사용에 대한 파일(112)로 캐시된다.
따라서, 파일 서버(110)는 또한 적어도 다음 환경을 인식하고 실행한다:
o NT 시큐리티 스타일. 파일(112)은 NT 시큐리티 스타일을 갖고 CIFS 파일 서 버 프로토콜을 사용하는 클라이언트 장치(120)에 의해 설정되는, 액세스 제어 제한(NT ACL)의 대응하는 세트를 갖는다.
클라이언트 장치(120)가 NFS 파일 서버 프로토콜을 사용하는 파일(112)을 액세스하도록 요구(121)를 생산하면, 파일 서버(110)는 요구(121)를 생산하는, 클라이언트 장치(120)와 결합된, 유닉스 유저를 결정한다. 유닉스 유저는 UID(유저 ID)를 갖는다.
바람직한 실시예에서, 파일 서버(110)는 유닉스 유저를 동등한 NT 유저로 맵(map)한다. 파일 서버(110)는 UID를 유닉스 유저와 동등한 유저인 SID(보안 ID)로 변환한다. 파일 서버(110)는 동등한 NT 유저(SID)에 대한 액세스 제어 제한을 실행한다.
파일 서버(110)는 유닉스 유저를 동등한 NT 유저로 맵하기 위해 다음 프로세스를 실행한다:
o 클라이언트 장치(120)는 NFS 파일 서버 프로토콜을 사용하는 파일 서버(110)와 접촉한다. NFS 파일 서버 프로토콜 요구(121)는 클라이언트 장치(120)와 결합된 유닉스 유저에 대한 UID를 포함한다.
o 파일 서버(110)는 유닉스 패스워드 파일(/etc/passwd)에서 UID를 찾아서, 유닉스 유저에 대한 유닉스 유저 이름을 확인한다. 유닉스 유저 이름은 유닉스 유저를 확인하는 문자와 숫자를 다 처리할 수 있는 문자열이다.
o 파일 서버(110)는 유닉스 유저 이름을 선택된 매핑 파일을 사용하는 NT 유저 이름으로 변환한다. 유닉스 유저 이름과 유사하게, NT 유저 이름은 NT 유저를 확인하는 문자와 숫자를 다 처리할 수 있는 문자열이다. 유닉스 유저 이름에 대한 이러한 변환이 없다면, 파일 서버(110)는 NT 유저 이름으로서, 변환 없이, 유닉스 유저 이름을 사용한다.
바람직한 실시예에서, 매핑 파일은 NT 유저 이름에 의해 NT 유저를 각각 확인하고, 동등한 유닉스 유저 이름을 NT 유저 이름과 결합하는 레코드의 세트를 포함한다.
o 파일 서버(110)는 NT 유저 이름에 대한 SID를 결정하기 위해 NT 도메인 제어기와 접촉한다. 이러한 NT 유저가 없다면, 파일 서버(110)는 맵되지 않은 유닉스 유저에 대한 선택된 파라미터를 사용한다. 바람직한 실시예에서, 이 선택된 파라미터는 디폴트에 의해 NT 유저 "게스트"로 설정된다.
o 파일 서버(110)는 NT 유저가 멤버인 모든 그룹의 SID를 얻기 위해 NT 도메인 제어기와 접촉한다.
파일 서버(110)는 시간 동안, 바람직하게는 수 시간동안 UID 대 SID 매핑을 캐시한다.
이와 다른 바람직한 실시예에서, 파일 서버(110)가 NT 유저에 대해 유닉스 유저를 맵할 수 없다면(예컨대, 도메인 확인이 소멸되면), 파일 서버(110)는 유닉스 펌의 적지 않은 제한적인 세트로 NT ACL을 맵한다. 파일 서버(110)는 NT ACL에 대응하고 유닉스 유저에 대응하여 이러한 유닉스 펌을 결정한다. 파일 서버(110)는 실제적인 유닉스 유저(UID)에 대한 맵된 액세스 제어 제한(유닉스 펌)을 실행한다.
매핑이 요구되는 시간에 파일 서버(110)가 NT ACL을 유닉스 펌의 세트로 맵하는, 동적인 허가 매핑을 파일 서버(110)가 실행해야 한다. 바람직한 실시예에서, 파일 서버(110)는 파일(112)을 가진 변환된 유닉스 펌을 캐시한다. 따라서, 액세스 제어 제한을 확인하기 위해서, 파일 서버(110)가 NT ACL이 설정되는 시간에서 NT ACL을 유닉스 펌의 세트로 맵하는, 정적인 허가 매핑을 파일 서버(110)가 실행한다.
파일 서버(110)는 정적인 허가 매핑을 얻기 위해 다음 프로세스를 실행한다:
o 파일 서버(110)는 파일(112)의 오너인 NT 유저를 결정하고, NT 유저를 동등한 유닉스 유저로 맵한다(파일 서버(110)는 NT 유저에 대한 SID를 유닉스 유저에 대한 UID로 맵한다).
o 파일 서버(110)는 파일(112)에 대한 NT ACL을 조사하고 어떤 "부정 액세스" 제공이 있는지를 결정한다.
o 파일(112)에 대한 NT ACL이 "부정 액세스" 제공을 갖지 않으면, NT ACL에 의해 제공되는 파일 액세스 제어 제한으로 일관된, "유저 허가"에 대한 엔트리를 갖는 유닉스 펌의 세트를 파일 서버(110)가 발생한다. 파일 서버(110)는 "그룹 허가"에 대한 유닉스 펌을 "다른 허가"에 대한 유닉스 펌과 동일하게 설정한다. 파일 서버(110)는 "다른 허가"에 대한 유닉스 펌을 존재한다면 "모든 허가"에 대한 NT ACL 엔트리와 동일하게 설정한다.
o 파일(112)에 대한 NT ACL이 "부정 액세스" 제공을 갖는다면, 파일 서버(110)는 요구(121)를 거절한다.
정적인 허가 매핑이 요구(121)를 생산하는 특별한 유저에 대해 응답하지 않 기 때문에, 파일 서버(110)는 NT ACL의 제공이 특별한 유저에 대한 것을 결정하기 위해 시도하지 않는다.
o 유닉스 시큐리티 스타일. 파일(112)은 유닉스 시큐리티 스타일을 갖고 NFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)에 의해 설정되는, 액세스 제어 제한(유닉스 펌)의 대응하는 세트를 갖는다.
클라이언트 장치(120)가 CIFS 파일 서버 프로토콜을 사용하는 파일(112)을 액세스하기 위해 요구(121)를 생산하면, 요구(121)를 생산하는, 클라이언트 장치(120)와 결합된, NT 유저를 파일 서버(110)가 결정한다. NT 유저는 SID(세션 ID)를 갖는다.
파일 서버(110)는 NT 유저를 동등한 유닉스 유저로 맵한다. 파일 서버(110)는 SID를 NT 유저와 동등한 유저인 UID로 변환한다. 파일 서버(110)는 동등한 유닉스 유저(UID)에 대한 액세스 제어 제한(유닉스 펌)을 실행한다.
파일 서버(110)는 NT 유저를 동등한 유닉스 유저로 맵하기 위해 다음 프로세스를 실행한다:
o 클라이언트 장치(120)는 CIFS 세션을 시작한다(클라이언트 장치(120)는 먼저 CIFS 파일 서버 프로토콜을 사용하는 파일 서버(110)와 접촉한다). 클라이언트 장치(120)는 NT 유저 이름을 파일 서버(110)에 전송한다.
o 파일 서버(110)는 NT 유저 이름을 매핑 파일을 사용하는 유닉스 유저 이름으로 변환한다. NT 유저 이름에 대한 이러한 변환이 없다면, 파일 서버(110)는 유닉스 유저 이름으로서, 변환 없이, NT 유저 이름을 사용한다.
o 파일 서버(110)는 유닉스 패스워드 파일(/etc/passwd)에서 유닉스 유저 이름을 찾아서, 유닉스 유저, 유닉스 유저에 대한 UID, 유닉스 유저의 주요 그룹, 및 유닉스 유저에 대한 주요 GID(그룹 ID)를 확인한다. 유닉스 패스워드 파일에 이러한 유닉스 유저 이름이 없다면, 파일 서버(110)는 맵되지 않은 NT 유저에 대한 선택된 파라미터를 사용한다. 바람직한 실시예에서, 이 선택된 파라미터는 디폴트에 의해 유닉스 유저 "노우바디"로 설정된다.
o 임의의 다른 그룹 및 유닉스 유저와 결합된 임의의 다른 GID를 결정하기 위해 유닉스 그룹 파일(/etc/groups)에서 유닉스 유저 이름을 파일 서버(110)가 찾는다.
(a) 파일(112)상에서 동작을 실행하는 요구(121), 또는 (b) 파일(112)에 대한 액세스 제어 제한을 설정하는 동작을 실행하는 요구(121)가, 예상되는 결과를 생산하도록 각 파일(112)은 파일 서버(110)에 의해 설정된 시큐리티 스타일을 갖는다.
파일(112)이 먼저 생성될 때, 파일 서버(110)는 그를 생성하기 위해 사용되는 파일 서버 프로토콜과 결합된 시큐리티 스타일과 동일하게 파일(112)에 대한 시큐리티 스타일을 설정한다. (이것은 이하에 설명된, 액세스 제어 트리에 의해 강요된 억제에 의해 한정된다.) 따라서, 파일(112)이 NFS 파일 서버 프로토콜을 사용하여 생성되면, 파일(112)에 대한 시큐리티 스타일은 유닉스 시큐리티 스타일로 설정된다. 유사하게, 파일(112)이 CIFS 파일 서버 프로토콜을 사용하여 생성되면, 파일(112)에 대한 시큐리티 스타일은 NT 시큐리티 스타일로 설정된다.
파일(112)이 변경된 액세스 제어 제한을 가질 때, 새로운 액세스 제어 제한과 결합된 시큐리티 스타일과 동일하게 파일(112)에 대한 시큐리티 스타일을 파일 서버(110)가 설정한다. (이것은 이하에 설명된, 액세스 제어 트리에 의해 강요된 억제에 의해 한정된다.) 따라서, 클라이언트 장치(120)가 파일(112)에 대한 유닉스 펌의 세트를 설정하면, 파일(112)에 대한 시큐리티 스타일은 유닉스 시큐리티 스타일로 설정된다. 유사하게, 클라이언트 장치(120)가 파일(112)에 대한 NT ACL을 설정하면, 파일(112)에 대한 시큐리티 스타일은 NT 시큐리티 스타일로 설정된다.
파일 서버(110)는 독출한 요구(121)를 수신하거나, 파일(112)에 대한 액세스 제어 제한을 볼 수 있다. 또한, 파일 서버(110)가 파일(112)에 대한 액세스 제어 제한에 대해 증가된 변화를 생산하기 위해 요구(121)를 수신할 때, 증가된 변화를 생산하기 전에 파일(112)에 대한 현재 액세스 제어 제한을 결정한다.
파일 서버(110)는 적어도 다음 환경에서 인식하고 실행한다:
o NT 시큐리티 스타일. 파일(112)은 NT 시큐리티 스타일을 갖고 CIFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)에 의해 설정되는, 액세스 제어 제한(NT ACL)의 대응하는 세트를 갖는다.
클라이언트 장치(120)가 NFS 파일 서버 프로토콜을 사용하는 파일(112)에 대한 액세스 제어 제한을 독출하거나 변경하는 요구(121)를 생산하면, 요구(121)를 생산하는, 클라이언트 장치(120)와 결합된, 유닉스 유저를 파일 서버(110)가 결정한다.
다음 예외를 가진, 파일 액세스 제어의 확인을 위해 상기 설명된 바와 같이 유닉스 펌의 세트로 NT ACL을 맵하는 동일한 프로세스를 파일 서버(110)가 실행한다.
액세스 제어 제한의 확인과 같지 않게, 파일(112)에 대한 액세스 제어 제한을 독출하거나 변경하는 요구(121)에 대해 다르게 액세스 제어 제한의 변환을 파일 서버(110)가 취급한다.
바람직하게는, 매핑이 요구되는 시간에 파일 서버(110)가 NT ACL을 유닉스 펌의 세트로 맵하는, 동적인 허가 매핑을 파일 서버(110)가 실행한다. NT 시큐리티 스타일은 유닉스 시큐리티 스타일보다 풍부하다-예컨대, 유닉스 시큐리티 스타일은 "부정 액세스" 제공을 갖지 않는다. 따라서, 파일 서버(110)가 NT ACL을 다른 유닉스 유저에 대해 다르게 나타나는 유닉스 펌의 세트로 맵할 수 있다. 예컨대, 오너가 챨스인 파일(112)에 대해, NT ACL이 특별히 앨런에 독출 액세스를 제공하나 특별히 베스에 대해 독출 액세스를 부정하면, 파일 서버(110)는 유저 앨런 및 베스의 각각에 다른 유닉스 펌을 제공할 것이다. 실제적인 NT ACL에 의해 제공되는 액세스와 조화하여, 하나의 세트는 앨런의 그룹에 의한 독출 액세스를 허용하고 하나의 세트는 베스의 그룹에 의한 독출 액세스를 허용하지 않을 것이다.
파일 서버(110)는 동적인 허가 매핑을 얻기 위해 다음 프로세스를 실행한다:
o 파일 서버(110)는 파일(112)의 오너인 NT 유저를 결정하고, NT 유저를 동등한 유닉스 유저로 맵한다(파일 서버(110)는 NT 유저에 대한 SID를 유닉스 유저에 대한 UID로 맵한다).
o 파일 서버(110)는 파일(112)에 대한 NT ACL을 조사하고 임의의 "부정 액세 스" 제공인지를 결정한다.
o 파일(112)에 대한 NT ACL이 "부정 액세스" 제공을 갖지 않으면, NT ACL에 의해 제공되는 파일 액세스 제어 제한으로 일관된 "유저 허가" 및 "다른 허가"에 대한 엔트리를 갖는 유닉스 펌의 세트를 파일 서버(110)가 발생한다. 파일 서버(110)는 "다른 허가"에 대한 유닉스 펌과 동일하게 "그룹 허가"에 대한 유닉스 펌을 설정한다.
o 파일(112)에 대한 NT ACL이 "부정 액세스" 제공을 가지면, 파일 서버(110)는 특별한 유닉스 유저에 임의로 적용할 지를 결정하기 위해 시도한다. 파일 서버가 말할 수 있다면, 이 특별한 파일(112) 및 이 특별한 유닉스 유저에 대해 현재 이용할 수 있는 액세스 제어 제한을 반영하는 유닉스 펌의 세트를 발생한다. 파일 서버(110)가 말할 수 없다면, 요구(121)를 거절한다. (이와 다르게, NT ACL에서의 임의의 "부정 액세스" 제공이 있다면 파일 서버(110)는 요구(121)를 거절할 수 있다.)
이와 다른 실시예에서, 파일(112)에 대한 액세스 제어 제한을 독출 또는 변경하는 요구(121)에 대한, 액세스 제어 제한의 확인과 유사하게, 파일 서버(110)는 정적인 허가 체킹을 실행한다.
파일(112)에 대한 액세스 제어 제한(액세스 시간 또는 변경 시간 등)에 영향을 미치지 않는 파일(112)의 속성을 변경하기 위해 요구(121)가 시도한다면, 파일(112)에 대한 액세스 제어 제한을 변화시키지 않고 파일 서버(110)가 이들 변경을 만든다.
파일(112)에 대한 모든 액세스 제어 제한이 아닌 어떤 것을 변경하기 위해 요구(121)가 시도한다면, 상기 설명된 바와 같이, 파일 서버(110)는 파일(112)에 대한 NT ACL에 대응하여 유닉스 펌의 세트를 발생한다. 파일 서버(110)는 요구(121)에 의해 구체화된 바와 같이 발생된 유닉스 펌을 변경한다. 파일 서버(110)가 파일(112)에 대한 NT ACL에 대응하여 유닉스 펌의 세트를 발생할 수 없다면, 파일 서버(110)는 요구(121)를 거절한다.
액세스 제어 제한을 세팅함에 있어서 하나의 차이는, NT 시큐리티 스타일에 대해, 파일(112)이 "READ-ONLY"로 구체적으로 설정될 수 있다는 것이다. 유닉스 시큐리티 스타일에 대해서, 파일(112)의 오너에 대한 WRITE 허가를 소거함에 의해서만 파일이 독출되도록 설정된다. CIFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)는 유닉스 시큐리티 스타일인 파일(112)의 READ-ONLY 속성을 설정하도록 시도할 때, 파일 서버(110)는 파일(112)에 대한 유닉스 펌에 있어서의 파일(112)의 오너에 대한 WRITE 허가를 소거한다.
o 유닉스 시큐리티 스타일. 파일(112)은 유닉스 시큐리티 스타일을 갖고 NFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)에 의해 설정되는, 액세스 제어 제한의 대응하는 세트(유닉스 펌)을 갖는다.
CIFS 클라이언트 장치(120)에 의해 유닉스 펌의 표시 또는 변경을 위해 유닉스 펌의 세트를 NT ACL로 맵하기 위해 파일 서버(110)가 다음 프로세스를 실행한다:
o "유저 허가"에 대한 유닉스 펌 엔트리와 같은 동일한 액세스 제어 제한을 제 공하는, "오너"에 대한 NT ACL 엔트리를 파일 서버(110)가 발생한다.
o "다른 허가"에 대한 유닉스 펌 엔트리와 같은 동일한 액세스 제어 제한을 제공하는, "에브리원"에 대한 NT ACL 엔트리를 파일 서버(110)가 발생한다.
o 가능하다면, 유저에 대한 유닉스 펌 엔트리와 같이 동일한 액세스 제어 제한을 제공하는, 실제적인 요구 유저에 대한 NT ACL 엔트리를 파일 서버(110)가 발생한다. 이 단계는 유닉스 유저를 UID-대-SID 캐시를 사용하는 동등한 NT 유저로 매핑하는 것을 요구할 수 있다.
유닉스 유저에 의한 NT ACL 엔트리의 변경과 유사하게, 요구(121)(NT 유저에 의한 유닉스 펌의 변경)가 파일(112)에 대한 액세스 제어 제한에 영향을 미치지 않는 파일(112)의 속성을 변경하도록 시도한다면, 파일 서버(110)는 파일(112)에 대한 액세스 제어 제한을 변화시키지 않고 이들 변경을 만든다.
파일(112)에 대한 모든 액세스 제어 제한이 아닌 어떤 것을 변경하도록 요구(121)가 시도하면, 상기 설명된 바와 같이, 파일 서버(110)는 파읽(112)에 대한 유닉스 펌의 세트에 대응하여 NT ACL을 발생한다. 파일 서버(110)는 요구(121)에 의해 구체화된 바와 같이 발생된 NT ACL을 변경한다.
액세스 제어 서브트리
바람직한 실시예에서, 파일 시스템(111)의 파일(112)은 브랜치 노드(branch node)의 세트 및 리프 노드(leaf node)의 세트를 갖는, 트리(tree)로 조직된다. 트리의 하나의 브랜치 노드는 루트 노드이고, 트리의 각 브랜치 노드는 트리의 서브트리에 대한 루트 노드이다. 파일 시스템(111)에 있어서, 각 브랜치 노드는 디렉토 리이고, 각 리프 노드는 파일(112)이다. 디렉토리는 루트 노드이기 위한 서브트리에서 이들 브랜치 노드 및 리프 노드에 대한 정보를 포함하는 파일(112)의 형태이다.
파일 서버(110)는 액세스 제어 모델의 한정된 세트를 각 서브트리와 관련시킨다. 파일 서버(110)가 유닉스 시큐리티 스타일 및 NT 시큐리티 스타일을 지원하는 바림직한 실시예에서, 파일 서버(110)는 각 서브트리를 NT-only 포맷, Unix-only 포맷, 또는 혼합된 포맷으로서 나타낸다.
NT-only 포맷
파일 서버(110)가 서브트리를 NT-only 포맷으로서 나타낼 때, NT 시큐리티 스타일을 갖는 파일(112)에 대한 서브트리내에서 파일(112)의 창조를 억제한다. NT 시큐리티 스타일과는 다른 서브트리내에서 파일(112)의 액세스 제어 모델을 변화시키는 것을 파일 서버(110)도 금지한다.
NT 시큐리티 스타일에 의하면, 새로운 파일(112)은 그들의 페어런트 노드로부터 NT ACL 셋팅을 물려 받는다. NFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)가 NT-only 포맷을 갖는 서브트리에서 파일(112)을 생성하도록 시도하면, 서브트리의 루트 노드의 NT-오너인 NT 유저와 동등한 유닉스 유저에 의해 파일(112)만 생성될 수 있다. (a) 동등한 UID로 오너인 NT 유저에 대한 SID를 매핑; (b) 파일(112)에 대한 레코드에서 UID를 기억; 및 (c) UID와 요구(121)의 UID를 비교함에 의해 요구(121)를 만드는 유닉스 유저가 동등한 지를 파일 서버(110)가 결정한다.
NT 시큐리티 스타일에 의하면, 특별한 "DELETE" 허가 및 특별한 "DELETE-CHILD" 허가이다. 유닉스 유저가 이들 허가를 가질지를 파일 서버(110)가 결정할 수 없다면, 요구(121)가 파일(112)의 오너(오너인 NT 유저의 동등한 유닉스 유저) 또는 유닉스 유저 "루트"로부터 인 것이 아니라면, NT-only 포맷 서브트리에서 파일(112)을 삭제하기 위해 요구(121)를 거절한다.
NT 시큐리티 스타일에 의하면, 특별한 "CHANGE-PERMISSION" 허가 및 특별한 "TAKE-OWNER" 허가이다. 유닉스 유저가 이들 허가를 가질지를 파일 서버(110)가 결정할 수 없다면, 요구(121)가 파일(112)의 오너(오너인 NT 유저의 동등한 유닉스 유저) 또는 유닉스 유저 "루트"로부터 인 것이 아니라면, NT-only 포맷 서브트리에서 파일(112)에 대한 임의의 허가를 설정하기 위해 요구(121)를 부정한다.
유닉스-유저 포맷
유사하게, 파일 서버(110)가 서브트리를 Unix-only 포맷으로서 나타낼 때, 유닉스 시큐리티 스타일을 갖는 파일(111)에 대해 서브트리내에서 파일(111)의 창조를 억제한다. 유닉스 시큐리티 스타일과는 다른 서브트리내에서 파일(111)의 액세스 제어 모델을 변화시키는 것을 파일 서버(110)도 금지한다. NT ACL을 설정하기 위한 시도는 NT 시큐리티 스타일에 대해 파일(112)에 대한 액세스 제어 모델을 변화시키고, Unix-only 포맷 서브트리에서 거절된다.
CIFS 파일 서버 프로토콜을 사용하는 클라이언트 장치(120)가 Unix-only 포맷에서 파일(112)을 생성할 때, 요구(121)를 만드는 NT 유저와 동등하게 유닉스 유저에 대해 파일(112)의 오너를 파일 서버(110)가 설정한다. 파일 서버(110)는 NT 유저에 대한 SID를 동등한 유닉스 유저에 대한 UID로 맵하고, 파일(112)의 오너를 설정하도록 UID를 사용한다.
유닉스 시큐리티 스타일에 의하면, "CHANGE-PERMISSION" 허가 또는 "TAKE-OWNER" 허가가 없다. Unix-only 포맷 서브트리에서 파일(112)에 대한 이들 허가를 설정하기 위해 파일 서버(110)는 항상 요구(121)를 부정한다.
혼합된 포맷
파일 서버(110)가 서브트리를 혼합된 포맷으로서 나타낼 때, 유닉스 시큐리티 스타일 또는 NT 시큐리티 스타일로 파일(111)의 창조를 허용한다. 유닉스 시큐리티 스타일 또는 NT 시큐리티 스타일에 대해 서브트리내에서 파일(111)의 액세스 제어 모델을 변화시키는 것을 파일 서버(110)가 금지하지 않는다.
파일 서버(110)에 대한 관리자는 제 1 포맷으로부터 제 2 포맷으로(예컨대, 혼합된 포맷으로부터 NT-only 포맷 또는 Unix-only 포맷으로) 서브트리의 지정을 변화시킬 수 있다. 제 2 포맷이 제 1 포맷과 호환성이 없을 때(예컨대, NT-only 포맷으로 변환된 서브트리가 유닉스 시큐리티 스타일인 노드를 포함한다), 파일(112)에 대한 허가를 설정하는 바와 같이 파일 서버(110)는 이들 파일(112)을 호환성이 없는 액세스 제어 모델로 변환한다. 허가를 검사만 하는 파일(112)에 대한 요구(121)는 파일(112)에 대한 위치에서 액세스 제어 모델을 사용하여 확인된다.
본 발명이 2개의 액세스 제어 모델에 대해서만 설명되더라도, 본 발명은 3개 이상의 액세스 제어 모델로 사용될 수 있다. 이와 다른 실시예에서, 파일 서버(110)에 의해 인식된 모든 액세스 제어 모델의 세트 이하인, 다중 액세스 제어 모델의 세트중의 하나에 대한 서브트리내에서 파일(112)을 억제하는 서브트리 포맷을 포함하는, 다량의 가능한 서브트리 포맷이 있다.
바람직한 실시예에서, 파일 시스템(111)의 루트 노드는 혼합된 포맷으로서 나타내어진다. 서브트리의 오너인 클라이언트 장치(120)는 파일 서버(110)에 대한 요구(121)에 의해 서브트리의 포맷을 변경할 수 있다; 따라서, 클라이언트 장치(120)는 NT-only 포맷, Unix-only 포맷, 혼합된 포맷을 갖도록 서브트리를 변경할 수 있다. 새로운 서브트리가 생성될 때, 파일 서버(110)는 그의 페어런트(parent)로서 동일한 포맷을 가짐으로써 새로운 서브트리를 나타낸다; 따라서, 이미 혼합된 포맷(디폴트)인 서브트리내에서 생성된다면 혼합된 포맷, 이미 NT-only 포맷인 서브트리내에서 생성된다면 NT-only 포맷, 및 이미 Unix-only 포맷인 서브트리내에서 생성된다면 Unix-only 포맷이다.
본 발명에 의하면, 멀티-프로토콜 파일 서버가 복수의 가능한 액세스 제어 모델중 하나의 특별한 액세스 제어 모델로 각 파일을 확인하고, 파일에 모든 액세스를 위해 특별한 액세스 제어 모델을 실행하는 장점이 얻어진다.
바람직한 실시예가 본 명세서에 설명되었지만, 본 발명의 개념, 범위, 및 정신내에서 다양한 변경이 가능하고, 이들 변경은 본 출원 후에 당업자들에게 명백해질 것이다.

Claims (30)

  1. 파일 서버에 실행되는 복수의 운영 시스템에 대응하는 복수의 시큐리티 스타일로부터 선택된 제 1 시큐리티 스타일로 파일 서버상의 제 1 파일을 확인하는 단계; 및
    상기 복수의 시큐리티 스타일 중 다른 하나에서의 액세스를 포함하여 상기 제 1 파일에 대한 모든 액세스에 대해 상기 제 1 시큐리티 스타일을 실행하는 단계를 포함하는 파일 서버의 운영방법.
  2. 제 1 항에 있어서, 상기 복수의 시큐리티 스타일이 윈도우 NT 시큐리티 스타일, 유닉스 시큐리티 스타일, 또는 윈도우 NT 시큐리티 스타일 및 유닉스 시큐리티 스타일 둘다를 포함하는 파일 서버의 운영방법.
  3. 삭제
  4. 제 1 항에 있어서,
    상기 제 1 파일을 파일 시스템의 파일의 서브세트와 결합시키는 단계; 및
    상기 파일의 서브세트를 상기 복수의 시큐리티 스타일의 보안 서브세트로 한정하는 단계를 포함하고,
    상기 파일 시스템 트리에서 허가를 설정하기 위한 시도는 상기 보안 서브세트로 제한되는 파일 서버의 운영방법.
  5. 삭제
  6. 삭제
  7. 삭제
  8. 제 1 항에 있어서, 상기 확인 및 실행 단계는 상기 제 1 시큐리티 스타일에서의 허가를 제 2 시큐리티 스타일로 매핑하는 단계를 더 포함하고, 상기 매핑은 동적으로 또는 정적으로 실행될 수 있는 파일 서버의 운영방법.
  9. 제 1 항에 있어서, 상기 확인 단계는,
    상기 제 1 시큐리티 스타일에서의 상기 제 1 파일과 결합된 허가의 제 1 세트를 상기 제 2 시큐리티 스타일에서의 허가의 제 2 세트로 변환하는 단계를 포함하고, 상기 허가의 제 2 세트는 상기 허가의 제 1 세트와 마찬가지로 제한적이고,
    상기 허가의 제 2 세트를 사용하여 상기 제 2 시큐리티 스타일에서의 파일 서버 요구를 실행하는 단계를 포함하는 파일 서버의 운영방법.
  10. 제 1 항에 있어서, 상기 실행 단계는,
    상기 제 1 시큐리티 스타일에서의 상기 제 1 파일과 결합된 허가의 제 1 세트를 인식하는 단계;
    상기 제 1 시큐리티 스타일과 결합된 제 1 유저형을 한정하는 단계;
    제 2 시큐리티 스타일과 결합된 제 2 유저형으로부터 상기 제 1 유저형으로 유저를 변환하는 단계; 및
    상기 제 1 유저형 및 상기 허가의 제 1 세트를 사용하는 상기 제 2 유저형으로부터 파일 서버 요구를 실행하는 단계를 포함하는 파일 서버의 운영방법.
  11. 삭제
  12. 삭제
  13. 삭제
  14. 삭제
  15. 삭제
  16. 파일 서버를 이용할 수 있는 파일의 세트를 포함하는 파일 서버로서,
    상기 각 파일은 상기 파일 서버에 이용할 수 있는 복수의 운영 시스템에 대응하는 복수의 시큐리티 스타일로부터 선택된 결합된 시큐리티 스타일을 가지며,
    상기 파일 서버는 상기 복수의 시큐리티 스타일 중 다른 하나에서의 액세스를 포함하여 상기 파일에 대한 모든 액세스를 위해 상기 결합된 시큐리티 스타일을 실행하는 파일 서버.
  17. 제 16 항에 있어서, 상기 복수의 시큐리티 스타일은 윈도우 NT 시큐리티 스타일, 유닉스 시큐리티 스타일, 또는 윈도우 NT 시큐리티 스타일 및 유닉스 시큐리티 스타일 둘다를 포함하는 파일 서버.
  18. 삭제
  19. 제 16 항에 있어서,
    상기 복수의 시큐리티 스타일의 보안 서브세트와 결합된 상기 파일시스템에서의 파일의 서브트리를 포함하고,
    상기 파일 서버는 상기 서브트리에서의 허가를 상기 보안 서브세트로 설정하려는 시도를 제한하는 파일 서버.
  20. 삭제
  21. 삭제
  22. 제 16 항에 있어서, 상기 파일 서버는 파일 서버 요구에 대응하는 상기 파일과 결합된 시큐리티 스타일을 변경할 수 있는 파일 서버.
  23. 삭제
  24. 제 22 항에 있어서, 상기 파일 서버는 제 1 시큐리티 스타일에서의 상기 파일과 결합된 허가의 제 1 세트를 제 2 시큐리티 스타일에서의 허가의 제 2 세트로 변환할 수 있고, 상기 허가의 제 2 세트는 상기 허가의 제 1 세트와 마찬가지로 제한적인 파일 서버.
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
KR1019990037448A 1999-09-03 1999-09-03 멀티-프로토콜 파일 서버의 파일 액세스 제어 KR100604241B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1019990037448A KR100604241B1 (ko) 1999-09-03 1999-09-03 멀티-프로토콜 파일 서버의 파일 액세스 제어

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1019990037448A KR100604241B1 (ko) 1999-09-03 1999-09-03 멀티-프로토콜 파일 서버의 파일 액세스 제어

Publications (2)

Publication Number Publication Date
KR20010026229A KR20010026229A (ko) 2001-04-06
KR100604241B1 true KR100604241B1 (ko) 2006-07-24

Family

ID=37527089

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1019990037448A KR100604241B1 (ko) 1999-09-03 1999-09-03 멀티-프로토콜 파일 서버의 파일 액세스 제어

Country Status (1)

Country Link
KR (1) KR100604241B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100681114B1 (ko) * 1999-12-18 2007-02-08 주식회사 케이티 접근권한 제어 시스템에서의 사용자 접근권한 제어방법

Also Published As

Publication number Publication date
KR20010026229A (ko) 2001-04-06

Similar Documents

Publication Publication Date Title
US6457130B2 (en) File access control in a multi-protocol file server
US6633872B2 (en) Extendible access control for lightweight directory access protocol
ES2284654T3 (es) Filtrado de un conjunto de autorizaciones que usa solicitudes de autorizacion asociadas con un conjunto de codigo.
US7562216B2 (en) System and method for applying a file system security model to a query system
US7200869B1 (en) System and method for protecting domain data against unauthorized modification
US6910041B2 (en) Authorization model for administration
US7065784B2 (en) Systems and methods for integrating access control with a namespace
US8239954B2 (en) Access control based on program properties
US7290279B2 (en) Access control method using token having security attributes in computer system
US5913025A (en) Method and apparatus for proxy authentication
US7421555B2 (en) System, device, and method for managing file security attributes in a computer file storage system
US20120131646A1 (en) Role-based access control limited by application and hostname
US8990900B2 (en) Authorization control
JP2009522694A (ja) オブジェクトへのユーザアクセスの管理
JP2003536176A (ja) 証拠ベースのセキュリティポリシーマネージャ
JP2006502472A (ja) リレーショナル・データベースへのアクセスを制御する方法
BRPI0711700A2 (pt) translado de diretiva de controle de acesso baseado em função para diretiva de autorização de recursos
US8635221B2 (en) Method, system, and program product for managing access to data items in a database
Bierman et al. Network configuration protocol (netconf) access control model
JP2000207363A (ja) ユ―ザ・アクセス制御装置
JP2000502825A5 (ko)
KR100604241B1 (ko) 멀티-프로토콜 파일 서버의 파일 액세스 제어
RU2134931C1 (ru) Способ обеспечения доступа к объектам в операционной системе мсвс
Bell Trusted Xenix Interpretation: Phase I
Jones Access control for client-server object databases

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130705

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20140708

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20150706

Year of fee payment: 10

LAPS Lapse due to unpaid annual fee