천국과 지옥 중 어디에서 꽃이 먼저 필까

상황

• 레거시 서버 중에 crontab을 사용하여 실행되는 배치들이 있다.
• 배치는 관리의 편의성을 위해 A사용자에서만 실행하도록 하고 있다.
• 추가된 배치가 B사용자의 파일을 삭제하는 작업을 필요로 했다.

조사

일반적인 Unix 권한 모델은 "이 파일은 누구 소유이고, 그 소유자만 뭘 할 수 있다"는 정적인 구조이다. 여기에 RBAC라는게 더 있어서 "이 사용자가 이 명령을 실행할 때만 다른 사용자 권한으로 승격시킨다"는 동적인 위임이 가능하게 된다.

적용

exec_attr 설정

프로파일의 이름, 실제 실행 가능한 명령어, 어떤 권한으로 실행할지 정의한다.

Batch File Cleanup:solaris:cmd:::/opt/scripts/foo_cleanup.sh:uid=foo

prof_attr 설정

exec_attr 뿐만 아니라 prof_attf에도 같은 이름으로 선언해줘야 프로파일을 인식한다.

Batch File Cleanup:::foo 소유 배치 로그 파일 정리 위임 프로파일:

user_attr 설정

특정 사용자가 프로파일을 사용할 수 있도록 연결한다.

bar::::profiles=Batch File Cleanup

실제 호출

pfexec을 사용해서 실행해야 만든 "user_attr → prof_attr → exec_attr" 순서로 프로파일을 확인하고 권한을 위임받아 실행하게 된다.

pfexec /opt/scripts/foo_cleanup.sh

연계 파일을 생성할 때 마지막 줄에 긴 공백이 들어가서 상대방이 적재 시 오류가 발생한다고 확인 요청이 왔다.

ByteBuffer buffer = ByteBuffer.allocate(data.length() * 3); //실제로는 숫자가 조금 다르다

ByteBuffer에 담을 데이터들은 data 변수에 들어가 있는데, 대충 한글이니 2바이트 등해서 주석에 왜 이렇게 계산을 하는지 잔뜩 적어놓았다. 물론 딱 맞는 숫자는 아니었고 무조건 미사용 공간이 생길 수 밖에 없는 구조다. 하지만 찾아보니 ByteBuffer를 allocate로 할당하면 그 capacity는 줄일 수가 없어서 꽉 안 채우면 미사용 공간이 공백으로 바뀌어 파일이 생성되는 것이었다.

buffer.flip();
byte[] bufferData = new byte[buffer.limit()];
buffer.get(bufferData);

flip()으로 읽기모드로 전환하면 position(시작)이 0으로, limit(끝)이 실제 쓴 데이터의 끝으로 변경되어, 이 상태로 복사하면 limit까지의 데이터만 복사되고, 뒤에 미사용 공간은 복사되지 않는다. 따라서 byte array를 생성할 때 길이를 buffer.limit()으로 설정하고, buffer.get()으로 버퍼에 담긴 데이터를 복사하면 된다.

문제가 있다면 다음에 buffer를 넘기는 메소드가 ByteBuffer 타입을 요구하는데, 위에서 생성한 bufferData는 byte array다.

//String foo = bar.foobar(buffer);
String foo = bar.foobar(ByteBuffer.wrap(bufferData);

이때 ByteBuffer.wrap(byte[])을 사용하면, 이미 존재하는 byte array를 ByteBuffer로 감싸기 때문에 예시로 쓴 foobar 메소드에서 타입 에러 없이 동작하게 된다. 이렇게 수정하여 연계 파일을 생성했을 때, 상대방의 연계 파일 적재 오류를 해결했다.