lkml.org 
[lkml]   [2009]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]
    Date
    I don't see any rationale for rt_tgsigqueueinfo and rt_sigqueueinfo to
    differ in their treatment of si_pid/si_uid (whatever that is). It just
    seems like common sense that they would match.

    Oleg and/or Sukadev have some patches floating around (maybe all in -mm?)
    that relate to setting those.

    I notice that POSIX says that si_pid and si_uid have reliable values
    whenever si_code <= 0 (what we call SI_FROMUSER() in asm/siginfo.h).
    (POSIX only has sigqueue() and kill() et al to send these, so a POSIX
    application never explicitly supplies the values. libc/libpthread do.
    The {t,tg,}kill syscalls all set si_pid to tgid already.)
    This means a POSIX-conformant application might check si_pid and si_uid and
    rely on them not being forged by some other process/user. Firstly this
    means that si_pid must be the POSIX PID, i.e. tgid, not the Linux TID
    (which is not a useful value in POSIX interfaces). Secondly it means the
    kernel should guarantee the correctness of these values (at least when
    crossing processes, might as well do always).

    I don't recall if the pending changes already use tgid, I think they do.

    I think what both calls should do is set si_pid to tgid and si_uid to uid
    whenever SI_FROMUSER(). This satisfies the POSIX and security trust
    concern, and makes them uniform. (In Sukadev's version, what si_pid value
    they fill in here depends on pid_ns details of sender and recipient.)

    Vis a vis Sukadev's changes, I also notice that si_uid ought to be
    translated for the recipient user_ns.


    Thanks,
    Roland


    \
     
     \ /
      Last update: 2009-02-27 01:07    [W:2.955 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site