From: Matthias Welwarsky <matthias.welwarsky@frontsite.de>
To: linux-kernel@vger.kernel.org
Subject: Problem understanding cap_emulate_setxuid()
Date: Fri, 05 Oct 2001 17:24:42 +0200 [thread overview]
Message-ID: <3BBDD0BA.94E53586@frontsite.de> (raw)
Hi all,
I'm having certain difficulties to understand how cap_emulate_setxuid()
in kernel/sys.c is supposed to work. I have a program that needs
CAP_SYS_NICE in order to create realtime threads.
For security reasons, I don't want the program to run as the root user.
So, I initially start the program setuid-root, then set CAP_SYS_NICE,
then drop root privileges. In pseudo-C, the program looks like this:
prctl(PR_SET_KEEPCAPS, 1);
cap_set(CAP_SYS_NICE);
seteuid(getuid());
However, from looking at cap_emulate_setxuid() I learned that when
switching the effective uid != 0, current->cap_effective is cleared,
regardless the settings of current->keep_capabilities. Huh? How is this
supposed to work at all? It at least seems to be a little impractical.
When a program is started setuid-root, getuid() == real_user_id and
geteuid() == 0. So, how would I drop root privileges without switching
the effective user id away from 0? Is this a bug in
cap_emulate_setxuid() or am I missing something?
It seems that with the current implementation, cap_effective ==
cap_permitted is only true when the effective uid == 0? However, to
minimize security implications, I'd like the process to run with
real_uid == effective_uid so that e.g. plugins cannot switch the
effective uid back to 0 and do funny things on root-owned files.
Shouldn't this be possible with capabilities?
best regards,
Matthias
--
Matthias Welwarsky
Fachschaft Informatik FH Darmstadt
Email: matze@stud.fbi.fh-darmstadt.de
"I bet the human brain is a kludge."
-- Marvin Minsky
reply other threads:[~2001-10-05 15:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3BBDD0BA.94E53586@frontsite.de \
--to=matthias.welwarsky@frontsite.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matze@stud.fbi.fh-darmstadt.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.