[lkml]   [1999]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectWhy is chmod(2)?

    I was talking about Unix system security recently and came
    across a strange question which you may be able to answer. The
    question is: "Why is chmod(2)", i.e. why are there so many
    kernel functions which take pathnames as parameters, when there
    are similar functions which take an fd.

    One obvious reason is of course compatibility. There are
    binaries that call chmod(2) and they should continue to work.
    But compatibility aside, can chmod(2) be implemented as chmod(3)
    using open(2) and fchmod(2) and is the same true for all other
    system calls which take pathnames as an argument?

    a. Is this desireable?
    b. Is it possible?

    I think it is often desireable in security related programs to
    use the f-version of a systemcall, because it ensures that you
    are talking about the same file in a sequence of related calls
    that are being done with the intention to check multiple things.
    An open fd is the only way for a process to refer directly to an
    inode (and a file offset, which is redundant in some cases, but
    not harmful).

    For example, in the suexec.c binary, which is part of the Apache
    distribution, there is code along the lines of

    cmd = argv[3];

    if (((lstat(cmd, &prg_info)) != 0) || (S_ISLNK(prg_info.st_mode))) {
    log_err("cannot stat program: (%s)\n", cmd);
    /* more checks on the stat buffer */
    /* the binary may be replaced, because these are nonatomic operations */

    execv(cmd, &argv[3]);

    Here, argv[3] may refer to different files because it is
    resolved multiple times, once in the lstat() and once in the
    execve() system calls. I think it would be desireable to be able
    to open() the cmd and then use fstat() and fexecve() which would
    ensure that we are at least talking about the same file each

    This would require r-right on cmd, though, because you cannot
    open(2) an execute-only file. Alternatively, you would need
    something like O_NULL and O_EXONLY as parameters to open(2),
    along the lines of O_RDONLY and O_RDWR. O_NULL would indicate
    that you want a file handle as a handle only, to be able to pass
    it to fchown() and fchmod() which only require that you are the
    owner of the file in question. O_EXONLY would require that you
    have execute permission on the file on question and you could
    use the resulting handle and pass it to fexecve().

    Does this make sense or am I missing something here? If not, why
    aren't chmod(2) and friends not implemented as library functions


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.028 / U:8.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site