From: Bernd Jendrissek <berndj@prism.co.za>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] new setprocuid syscall
Date: Fri, 23 Feb 2001 19:13:45 +0200 [thread overview]
Message-ID: <20010223191345.A5166@prism.co.za> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(Please CC me - I am not subscribed)
BERECZ Szabolcs (szabi@inf.elte.hu) wrote:
> Here is a new syscall. With this you can change the owner of a running
> procces.
Stupid question: why? Not so stupid: why, giving examples? Does the
target process expect to be re-owned? Remember that a process can easily
remember its original uid, and become confused later after you stole it.
> +++ linux-2.4.1-setprocuid/kernel/sys.c Mon Feb 19 21:52:51 2001
[...]
> +asmlinkage long sys_setprocuid(pid_t pid, uid_t uid)
> +{
> + struct task_struct *p;
> +
> + if (current->euid)
> + return -EPERM;
> +
> + p = find_task_by_pid(pid);
> + p->fsuid = p->euid = p->suid = p->uid = uid;
> + return 0;
> +}
How about a *slow* (for everyone) setprocuid(2)? Is it still possible in
current kernels to "lock out" all other processes even on SMP boxen? If
so, make sure the target is not in a syscall (EAGAIN until it's out), then
change the world. Or, ...
A gross hack: make a special case in do_signal that overloads some
rarely-used signal. Send that signal with needed magic to the target.
When the target wants to re-enter userland for whatever reason, it notices
that this ain't a signal, but a backdoor to make it change its uid *itself*
so the assumption
Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> There is an assumption in the kernel that only the task changes its
> own uid and other related data.
remains true. setprocuid(2) blocks until the signal is delivered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6lppADaF1aCTutCYRAiKnAJ4jHUTN9XfsaVXlOnuhQy4JtS/slACcCr17
1g5KvyDY7LCFGFKG/BZIfC4=
=DUal
-----END PGP SIGNATURE-----
next reply other threads:[~2001-02-23 17:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-23 17:13 Bernd Jendrissek [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-02-20 14:19 [PATCH] new setprocuid syscall Petr Vandrovec
2001-02-19 22:18 BERECZ Szabolcs
2001-02-20 5:01 ` Peter Samuelson
2001-02-20 10:53 ` Martin Dalecki
2001-02-20 13:00 ` Peter Samuelson
2001-02-20 11:42 ` Alan Cox
2001-02-20 13:11 ` Peter Samuelson
2001-02-20 13:52 ` Alan Cox
2001-02-20 17:04 ` BERECZ Szabolcs
2000-01-01 0:28 ` Pavel Machek
2001-02-21 4:19 ` Peter Samuelson
2001-02-20 12:14 ` BERECZ Szabolcs
2001-02-20 12:52 ` Peter Samuelson
2001-02-20 12:02 ` Philipp Rumpf
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=20010223191345.A5166@prism.co.za \
--to=berndj@prism.co.za \
--cc=linux-kernel@vger.kernel.org \
/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