ACL implementation on MINIX 2 - Minix

This is a discussion on ACL implementation on MINIX 2 - Minix ; Hello, I have to implement an ACL (Access Control List) on Minix 2 and I would like any help on where to start . I supose I can just have a file with the Access Control List (let's say /etc/acl.acl). ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: ACL implementation on MINIX 2

  1. ACL implementation on MINIX 2

    Hello,

    I have to implement an ACL (Access Control List) on Minix 2 and I
    would like any help on where to start . I supose I can just have a
    file with the Access Control List (let's say /etc/acl.acl). Making a
    script to modify this file would be easy.
    Now the problem is checking if a user has rights or not to do whatever
    with a file. I think I can just modify protect.c in /usr/src/fs and
    recompile that but don't understand well some parts of that code.

    For example, in do_chmod, it says it gets (name, mode) but the
    function does not take any parameters.
    Same in do_chown. Its apparently using a global variable fp (file
    pointer).
    do_umask: don't know what this does :S.
    do_access: idem
    forbidden(rip, access_desired): ...
    read_only(ip): ...

    Anyway, I would like to know if any of you can explain me what each of
    this functions does and if its enogh to modify them to get my ACL
    working. And, if possible, how to get a char* with the file name, and
    the uid to check my ACL file to see if it has the permissions.

    Thanks (any help / page / tutorial will be nice),
    Diego


  2. Re: ACL implementation on MINIX 2

    By the way, I am trying to do a basic implementation using a /etc/
    acl.conf file...
    Adding the code to check in forbidden function in /usr/src/fs/
    protect.c but I have two problems:

    1) I cannot get the full name (path) of the file... user_path global
    variable gives me the related path.
    2) If I do fopen or execute anything (with system), it hangs up!

    I am checking if the user_path is my acl.conf to avoid some infinite
    loops, but it just hangs up when trying to fopen the file.

    Any idea?


  3. Re: ACL implementation on MINIX 2

    gdiego wrote:
    [...]
    > 2) If I do fopen or execute anything (with system), it hangs up!


    I can't help feeling that trying to open a file (with will involve
    communicating with the fs server) from *within* the fs server is probably a
    bad idea... you're probably deadlocking, as the server can't respond to the
    request until it's finished the current request, which it won't be able to do
    because it's blocked waiting for the request to finish. (There *is* only one
    fs server, and it's strictly single-threaded, right?)

    Possible suggestions:

    - store the ACL in memory, and have a user-space tool read it off disk and
    then feed the data to the fs server. That way, the fs server won't step on its
    own toes trying to read it off disk itself.

    - have the fs server use its own internal mechanisms to read the ACL, so that
    instead of using fopen() you're touching the disk directly. This will probably
    be unpleasant.

    - write a completely new fs server, that piggybacks on top of the existing
    server. That way, your new server can send the existing one requests without
    worrying about reentrancy issues. It also means that your code remains
    completely isolated from the existing server.

    --
    ┌── dg*cowlark.com ─── http://www.cowlark.com ──────────────── ──

    │ "The first 90% of the code takes the first 90% of the time. The other 10%
    │ takes the other 90% of the time." --- Anonymous

  4. Re: ACL implementation on MINIX 2

    Is there any easy way to do this, cause I can't even get the full path
    name of the file in protect.c (I only have a rip (inode pointer)).

    Thx,
    Diego

    On Feb 13, 8:02 am, David Given wrote:
    > gdiego wrote:
    >
    > [...]
    >
    > > 2) If I do fopen or execute anything (with system), it hangs up!

    >
    > I can't help feeling that trying to open a file (with will involve
    > communicating with the fs server) from *within* the fs server is probablya
    > bad idea... you're probably deadlocking, as the server can't respond to the
    > request until it's finished the current request, which it won't be able to do
    > because it's blocked waiting for the request to finish. (There *is* only one
    > fs server, and it's strictly single-threaded, right?)
    >
    > Possible suggestions:
    >
    > - store the ACL in memory, and have a user-space tool read it off disk and
    > then feed the data to the fs server. That way, the fs server won't step on its
    > own toes trying to read it off disk itself.
    >
    > - have the fs server use its own internal mechanisms to read the ACL, so that
    > instead of using fopen() you're touching the disk directly. This will probably
    > be unpleasant.
    >
    > - write a completely new fs server, that piggybacks on top of the existing
    > server. That way, your new server can send the existing one requests without
    > worrying about reentrancy issues. It also means that your code remains
    > completely isolated from the existing server.
    >
    > --
    > ┌── dg*cowlark.com ───http://www.cowlark.com────...────
    > │
    > │ "The first 90% of the code takes the first 90% of the time. Theother 10%
    > │ takes the other 90% of the time." --- Anonymous




  5. Re: ACL implementation on MINIX 2



    David Given writes:

    > gdiego wrote:
    > [...]
    >> 2) If I do fopen or execute anything (with system), it hangs up!

    >
    > I can't help feeling that trying to open a file (with will involve
    > communicating with the fs server) from *within* the fs server is probably a
    > bad idea... you're probably deadlocking, as the server can't respond to the
    > request until it's finished the current request, which it won't be able to do
    > because it's blocked waiting for the request to finish. (There *is* only one
    > fs server, and it's strictly single-threaded, right?)
    >
    > Possible suggestions:
    >
    > - store the ACL in memory, and have a user-space tool read it off disk and
    > then feed the data to the fs server. That way, the fs server won't step on its
    > own toes trying to read it off disk itself.
    >
    > - have the fs server use its own internal mechanisms to read the ACL, so that
    > instead of using fopen() you're touching the disk directly. This will probably
    > be unpleasant.
    >
    > - write a completely new fs server, that piggybacks on top of the existing
    > server. That way, your new server can send the existing one requests without
    > worrying about reentrancy issues. It also means that your code remains
    > completely isolated from the existing server.


    Actually I wonder about the store-ACLs-in-a-file approach. This
    introduces recursion anyway since to open the /etc/acls.conf you'd
    have to open a file for which you'd have to check the
    ACLs. Furthermore, paths are meaningless in Unix -- linking the file
    to another name would circumvent the ACLs

    My suggestion would be to store the ACLs in the inode or specially
    allocated blocks linked to the inode. The price one would have to pay
    for that would be to modify all fsck, mkfs etc code.

    Regards -- Markus


  6. Re: ACL implementation on MINIX 2

    I have been investigating this / getting help from friends, and I have
    a problem...

    If I call open / close then I have a deadlock but not calling
    common_open and do_close...
    I cant call read but can call do_read...
    Now, I can have my ACL in /etc/acl.conf but (this is not easy)... I
    have to change readwrite cause read writes in user space (adds some
    chunk to buffer).

    Can anyone help me with this, ... I dont understand all this code, its
    really ugly (lot of global vars, short names, structs everywhere)...

    Its easier to modify my debian lol

    Thanks,
    Diego

    On Feb 13, 8:31 am, Markus E Leypold
    wrote:
    > David Given writes:
    > > gdiego wrote:
    > > [...]
    > >> 2) If I do fopen or execute anything (with system), it hangs up!

    >
    > > I can't help feeling that trying to open a file (with will involve
    > > communicating with the fs server) from *within* the fs server is probably a
    > > bad idea... you're probably deadlocking, as the server can't respond to the
    > > request until it's finished the current request, which it won't be able to do
    > > because it's blocked waiting for the request to finish. (There *is* only one
    > > fs server, and it's strictly single-threaded, right?)

    >
    > > Possible suggestions:

    >
    > > - store the ACL in memory, and have a user-space tool read it off disk and
    > > then feed the data to the fs server. That way, the fs server won't step on its
    > > own toes trying to read it off disk itself.

    >
    > > - have the fs server use its own internal mechanisms to read the ACL, so that
    > > instead of using fopen() you're touching the disk directly. This will probably
    > > be unpleasant.

    >
    > > - write a completely new fs server, that piggybacks on top of the existing
    > > server. That way, your new server can send the existing one requests without
    > > worrying about reentrancy issues. It also means that your code remains
    > > completely isolated from the existing server.

    >
    > Actually I wonder about the store-ACLs-in-a-file approach. This
    > introduces recursion anyway since to open the /etc/acls.conf you'd
    > have to open a file for which you'd have to check the
    > ACLs. Furthermore, paths are meaningless in Unix -- linking the file
    > to another name would circumvent the ACLs
    >
    > My suggestion would be to store the ACLs in the inode or specially
    > allocated blocks linked to the inode. The price one would have to pay
    > for that would be to modify all fsck, mkfs etc code.
    >
    > Regards -- Markus




+ Reply to Thread