안녕하세요, 모스크바에 살고 있는 개발자 윤진입니다.


C로 개발을 할때는 헤더파일에 온갖 함수선언을 하며,

공동작업을 하는 개발자들끼리 전체적인 그림을 그리곤 했습니다.

그럴때마다 Java의 interface 기능이 무척이나 부러웠죠. :)


C#에서는 다양한 방법으로 모듈을 설계&구현할 수 있습니다.

- interface

- abstract class

- partial class

- virtual method


그렇지만, 각각이 목적과 쓰임이 다릅니다.

interface는 1) 메소드, 2) 속성, 3) 인덱서, 4) 이벤트 만을 사전에 선언하여,

해당 interface를 상속받는 class가 빈 껍데기를 구현하도록 유도하고 있습니다.

만약 아래 코드처럼 interface에 필드를 넣으면, 컴파일 에러가 발생합니다.

컴파일러 : "인터페이스는 필드를 포함할 수 없습니다"

    interface InterfaceWithVariable
    {
        string s; // Error
        int InterfaceMethod();
    }

변수가 있다는 것은 특정 상태를 기억한다는 것이기에,

이런 '상태'라는 것은 구현영역에서 처리하는게 맞습니다.


abstract class는 abstract 타입의 1) 메소드, 2) 속성, 3) 인덱서, 4) 이벤트가 하나 이상 포함된 class 입니다.

추가 구현이 필요한 abstract 타입 있다는 것 외에는 일반 class 정의하듯 만들면 됩니다.

그렇기에 필드에 대한 별도의 제약사항은 없습니다.

    abstract class AbstractWithVariable
    {
        int i;
        protected abstract int AbstractMethod(int argument);
    }

위의 예처럼 얼마든지 class 필드를 만들 수 있습니다.


partial class도 abstract class처럼 필드에 대한 제약이 없습니다.

일반 class를 복수개로 쪼개놓은 것이기 때문에, 분리된 것을 합치면 일반 class가 됩니다.

한 partial class에서 정의한 변수를 다른 다른 partial class에서 사용할 수 있습니다.

    partial class PartialWithVariable
    {
        int i = 10;
    }

    partial class PartialWithVariable
    {
        public void Print()
        {
            Console.WriteLine(i);
        }
    }


virtual method는 상속과정에서 부모-자식 간에 메소드 처리방식을 규정하기 때문에,

abstract나 partial처럼 변수에 대한 제약이 없습니다.

    public class VirtualClass
    {
        int i;
        public virtual void Print(int i)
        {
            Console.WriteLine(i);
        }
    }


이상으로 필드에 얽힌 간단한 이야기를 마치겠습니다.

끝_

디버스의 메소드/시그널에도 스맥을 적용할 수 있습니다.

스맥이 적용된 디버스 메소드/시그널에는 권한이 있는 프로세스만 접근할 수 있습니다.

브로드캐스팅하는 인터페이스라 할지라도 권한이 없으면 접근할 수 없습니다.


스맥이 최초부터 디버스를 지원하진 않았습니다.

하지만, 디버스로 주고받는 정보를 누구에게나 노출하는 것은 위험할 수 있습니다.

따라서 2012년 2월에 한 용자가 디버스에 스맥을 이식해버렸습니다.


그리고 3년이 지난 지금은 스맥의 주요 기능 중 하나가 되었죠.



스맥을 위한 manifest 파일 만드는 법은 이전 포스팅에서 설명한 바 있습니다.

"SMACK 레이블을 긋기 위한 manifest의 모든 것 - 파일편", http://storycompiler.tistory.com/49

이 manifest 파일에서 디버스를 위한 스맥권한도 지정할 수 있습니다.



{service name}.manifest 파일은 패키지가 설치될 때 함께 설치됩니다.

manifest 내용 중 DBUS와 관련된 항목이 있으면,

rpm-security-plugin에 의해서 파싱되어 manifest.{service name}.conf 파일로 추출됩니다.

manifest.{service name}.conf 파일은 디버스 설정파일로 활용되지요.


<assign> <dbus name="org.dbus.name" own="DOMAIN_NAME" bus="system"> <!-- 중략 --> </dbus> </assign>

디버스는 <assign> 태그에서 설정해주어야 합니다.

<assign> 태그는 파일/디렉토리에 스맥룰을 적용할 때도 사용하고 있습니다.

- dbus name : D-Bus의 버스명을 적어줍니다.

- own : dbus-service를 정의한 프로세스의 도메인이름

- bus : "system" 혹은 "session"


<assign> <dbus name="org.dbus.name" own="DOMAIN_NAME" bus="system"> <node name="/org/dbus/object/name"> <interface name="org.dbus.interface.name1"> <method name="methodName1"> <annotation name="org.tizen.smack" value="DOMAIN_NAME::COMPONENT_1" /> </method> <method name="methodName2"> <annotation name="org.tizen.smack" value="DOMAIN_NAME::COMPONENT_2" /> </method> </interface> <interface name="org.dbus.interface.name2"> <annotation name="org.tizen.smack" value="DOMAIN_NAME::COMPONENT_3" /> </interface> </node> </dbus> </assign>

<node> 태그에는 오브젝트 이름을 적어줍니다. <node> 안에는 다수의 <interface>를 적어넣을 수 있습니다.

<interface> 태그에는 인터페이스 이름을 적어줍니다. <interface> 안에는 다수의 <method>를 적을 수 있습니다.

<method> 태그에는 메소드의 이름을 적어줍니다. <method> 내에는 <annotation> 태그가 하나 들어갑니다.

<annotation>에는 메소드에 접근하기 위한 스맥권한을 명시합니다.

annotation name은 스맥을 위한 키이름을 적어야 합니다.

키이름은 플랫폼마다 다를 수 있습니다.

여기서는 타이젠 플랫폼에서 사용하는 org.tizen.smack을 사용하겠습니다.

value에는 스맥레이블을 적으면 됩니다.


<assign> <dbus name="org.dbus.name" own="DOMAIN_NAME" bus="system"> <node name="/org/dbus/object/name"> <interface name="org.dbus.interface.name> <annotation name="org.tizen.smack" value="DOMAIN_NAME::COMPONENT" /> </interface> </node> </dbus> </assign> 

위의 예에서는 interface에 속한 모든 method / signal에 공통의 스맥레이블을 적용할 수 있습니다.

<interface> 태그 안에 <method> 대신 <annotation> 태그를 입력했습니다.

그러면 interface에 속한 모든 method에 annotation에서 지정한 스맥레이블이 적용됩니다.


타이젠 플랫폼에서 실제로 사용하고 있는 manifest를 보시죠.

"git://review.tizen.org/framework/system/crash-worker" / tizen_2.3 브랜치,

packaging/crash-worker.manifest 파일에서 디버스 항목을 추려보았습니다.

<assign>
<dbus name="org.tizen.system.crash" own="crash-worker" bus="system">
<node name="/Org/Tizen/System/Crash/Crash">
<interface name="org.tizen.system.crash.Crash">
<!-- dbus smack label "crash-worker::crashctl" -->
<method name="dump_log">
<annotation name="com.tizen.smack" value="crash-worker::crashctl" />
</method>
<method name="delete_dump">
<annotation name="com.tizen.smack" value="crash-worker::crashctl" />
</method>
</interface>
</node>
</dbus>
</assign>

위의 예제에서는 "dump_log"와 "delete_dump" 두 개의 메소드에,

"crash-worker::crashctl" 스맥레이블을 부여했습니다.

다른 메소드도 존재하지만 굳이 저 두 개의 메소드에만 스맥레이블을 부여하기 위하여 사용한 것으로 보입니다.


이것으로 manifest에 대한 설명을 정리하도록 하겠습니다.

그럼 오늘도 좋은 하루 보내세요~


끝_


* SMACK에 대한 이야기를 쌓아본다

http://storycompiler.tistory.com/51


* References

https://wiki.tizen.org/wiki/Security/Application_installation_and_Manifest

https://wiki.tizen.org/wiki/Security/Tizen_2.X_dbus


+ Recent posts