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 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.