Hi!
> The conclusion: it's cannot be implemented without slowdown.
> So ignore my patch.
Of course it can.
One possibility would be to implement it as ptrace(SETUID) and only
allow it if we know other task is not in kernel. [And then cean up any
remaining problems.]
--
Philips Velo 1: 1"x4"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Please CC me - I am not subscribed)
BERECZ Szabolcs ([EMAIL PROTECTED]) 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 proces
[BERECZ Szabolcs]
> The conclusion: it's cannot be implemented without slowdown.
Or: it cannot be implemented 100% safely and correctly without slowdown.
If you know the use you wish to put this to, and are willing to risk a
permission check somewhere being confused momentarily by a non-atomic
The conclusion: it's cannot be implemented without slowdown.
So ignore my patch.
Bye,
Szabolcs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
> Fair enough but could you explain the potential problems? And how is
> it different from sys_setpriority?
Suppose you change a tasks uid in parallel with the set of conditionals
in setuid - just as one example. Or you change uid _during_ a quota operation.
Or during sys5 ipc ops.
All of these
On 20 Feb 01 at 7:11, Peter Samuelson wrote:
> [Alan Cox]
> > There is an assumption in the kernel that only the task changes its
> > own uid and other related data.
>
> Fair enough but could you explain the potential problems? And how is
> it different from sys_setpriority?
Look at what fs/ope
[Alan Cox]
> There is an assumption in the kernel that only the task changes its
> own uid and other related data.
Fair enough but could you explain the potential problems? And how is
it different from sys_setpriority?
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
[Peter Samuelson]
> > Race -- you need to make sure the task_struct doesn't disappear out
> > from under you.
> >
> > Anyway, why not use the interface 'chown uid /proc/pid'? No new
> > syscall, no arch-dependent part, no user-space tool, etc.
[Martin Dalecki]
> Becouse of exactly the same r
[BERECZ Szabolcs]
> > Race -- you need to make sure the task_struct doesn't disappear out
> > from under you.
>
> Yes, but we need a write_lock, not a read_lock.
No, it's a read_lock because it is locking the task *list*, which is
not being changed. The only thing being changed is data within
On Mon, 19 Feb 2001, Peter Samuelson wrote:
> [BERECZ Szabolcs]
> > + p = find_task_by_pid(pid);
> > + p->fsuid = p->euid = p->suid = p->uid = uid;
> Race -- you need to make sure the task_struct doesn't disappear out
> from under you.
Yes, but we need a write_lock, not a read_lock.
> diff -urN linux-2.4.1/arch/i386/kernel/entry.S
> linux-2.4.1-setprocuid/arch/i386/kernel/entry.S
> --- linux-2.4.1/arch/i386/kernel/entry.SThu Nov 9 02:09:50 2000
> +++ linux-2.4.1-setprocuid/arch/i386/kernel/entry.S Mon Feb 19
> 22:12:00 2001
> @@ -645,6 +645,7 @@
> .long S
> + if (task)
> + task->fsuid = task->euid = task->suid = task->uid = attr->ia_uid;
> + read_unlock (&tasklist_lock);
There is an assumption in the kernel that only the task changes its own uid
and other related data.
Alan
-
To unsubscribe from this list: send the line "unsu
Peter Samuelson wrote:
>
> [BERECZ Szabolcs]
> > Here is a new syscall. With this you can change the owner of a running
> > procces.
>
> > + if (current->euid)
> > + return -EPERM;
>
> Use capable().
>
> > + p = find_task_by_pid(pid);
> > + p->fsuid = p->euid =
[BERECZ Szabolcs]
> Here is a new syscall. With this you can change the owner of a running
> procces.
> + if (current->euid)
> + return -EPERM;
Use capable().
> + p = find_task_by_pid(pid);
> + p->fsuid = p->euid = p->suid = p->uid = uid;
Race -- you need to ma
Hi!
Here is a new syscall. With this you can change the owner of a running
procces.
I put the architecture dependent part (syscall NR, and function address)
only to the i386, becouse I'm not familiar with the other arch.
What do you think about it?
I think it's useful, but...
Now I'm writing the
15 matches
Mail list logo
