public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Peng Yu <pengyu.ut@gmail.com>
To: noloader@gmail.com
Cc: libc-help <libc-help@sourceware.org>
Subject: Re: definitions of uid and euid
Date: Tue, 2 Feb 2021 21:24:59 -0600	[thread overview]
Message-ID: <CABrM6wn9O0dagmoPPCcTQX+PvzsdNmCrvaMiNdoLUzu7yroQUg@mail.gmail.com> (raw)
In-Reply-To: <CAH8yC8=5hAqxk55TOo0M8_vp0viR0uVd6_YevfZWejDc1EWeoQ@mail.gmail.com>

This document is pretty old. Is it still the most relevant document
nowadays.  Given the shortcoming mentioned in the document. Nothing
has been changed to accommodate the shortcomings since then?

On 2/2/21, Jeffrey Walton via Libc-help <libc-help@sourceware.org> wrote:
> On Tue, Feb 2, 2021 at 12:22 PM Peng Yu via Libc-help
> <libc-help@sourceware.org> wrote:
>>
>> `man getuid` says the following without explaining what real user ID
>> and effective user ID are.
>>
>> - getuid() returns the real user ID of the calling process.
>> - geteuid() returns the effective user ID of the calling process.
>>
>> Could anybody explain the definitions of uid and euid, and provide a
>> minimum working example demonstrating when they are different? Thanks.
>
> Also see Chen, Wagner and Dean's
> https://www.usenix.org/conference/11th-usenix-security-symposium/setuid-demystified:
>
>    Access control in Unix systems is mainly based on
>    user IDs, yet the system calls that modify user IDs
>    (uid-setting system calls), such as setuid, are poorly
>    designed, insufficiently documented, and widely
>    misunderstood and misused. This has caused many
>    security vulnerabilities in application programs.
>    ...
>
> Jeff
>


-- 
Regards,
Peng

      reply	other threads:[~2021-02-03  3:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 17:04 Peng Yu
2021-02-02 17:54 ` Paul Smith
2021-02-03  1:49 ` Jeffrey Walton
2021-02-03  3:24   ` Peng Yu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABrM6wn9O0dagmoPPCcTQX+PvzsdNmCrvaMiNdoLUzu7yroQUg@mail.gmail.com \
    --to=pengyu.ut@gmail.com \
    --cc=libc-help@sourceware.org \
    --cc=noloader@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).