Re: [9fans] Novice question - run as other

Re: [9fans] Novice question - run as other

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 102 bytes --]

It worked, I believe you just didn't notice.  The echo process became
none and then immediately died.

[-- Attachment #2: Type: message/rfc822, Size: 2997 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Novice question - run as other
Date: Wed, 17 Mar 2004 12:54:46 +0400 (AMT)
Message-ID: <200403170854.i2H8sk2J083766@adat.davidashen.net>

> >> > a program from a shell script and change the user it runs as.
> >>
> >> The security model doesn't allow this. Perhaps by running it as a service
> >> on a cpu.  Check /sys/src/cmd/auth/cron.c and cap(3).  For somethings
> >> you can cpu over and change to a different uid:
> > 
> > The following works:
> ...
> > 	fd>=0 && (write(fd,"none",strlen("none"))!=-1)
>
> That's not what you asked.
>

? Is none not user?

cpu% grep none /adm/users
0:none:adm

cpu% none
cat /env/user
none

I want a program to run as a different user. From C, it means opening
'#c/user' and writing the user's name there. The security model is
a separate issue, the call either succeeds or fails, 
but it is a consequence of security limitations, and not of the API.

My question was how to do the same from rc. 

@{echo -n none > '#c/user' ; while() {sleep 1} }

succeeds but does not change the owner of the process. Why?

Dav id

Re: [9fans] Novice question - run as other

[ron minnich]

>My question was how to do the same from rc. 

>@{echo -n none > '#c/user' ; while() {sleep 1} }

>succeeds but does not change the owner of the process. Why?

well, seems it would be bad if all you had to do to change userid was 
echo into '#c/user'

So, starting from that, the why should be apparent.

ron

Re: [9fans] Novice question - run as other

[rog]

> well, seems it would be bad if all you had to do to change userid was 
> echo into '#c/user'

but if echo was built in to the shell (as it is in some other systems)
that's all you *would* have to do!

Re: [9fans] Novice question - run as other

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

If all you wanted to do was change the user id, that
would be true.  However, without running newns() it's
kind of useless/dangerous.

[-- Attachment #2: Type: message/rfc822, Size: 1935 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Novice question - run as other
Date: Wed, 17 Mar 2004 17:13:58 0000
Message-ID: <0e0cb432b6b2920c12c7b9bde24f0e27@vitanuova.com>

> well, seems it would be bad if all you had to do to change userid was 
> echo into '#c/user'

but if echo was built in to the shell (as it is in some other systems)
that's all you *would* have to do!

Re: [9fans] Novice question - run as other

[David Tolpin]

>
> >@{echo -n none > '#c/user' ; while() {sleep 1} }
>
> >succeeds but does not change the owner of the process. Why?
>
> well, seems it would be bad if all you had to do to change userid was 
> echo into '#c/user'
>
> So, starting from that, the why should be apparent.

The 'Why' was about a different issue.

The question was why the C program behaves differently than
the shell script.  The C program just writes to #c/user to
change the owner of the process.

The answer is that writing to #c/user is special
in the sense that although it is a part of namespace, it changes
the state of the process space, which is only apparent if you look
into the kernel source.

A more general conclusion is that for tasks where writing to
or reading from files reflects or affects process space, and not
name space, rc is not suitable and C code must be written.

I am now into the sources to understand which files in the namespace
are actually not in it, but in the process space.

David Tolpin
http://davidashen.net/

Re: [9fans] Novice question - run as other

[ron minnich]

On Wed, 17 Mar 2004, David Tolpin wrote:

> The question was why the C program behaves differently than
> the shell script.  The C program just writes to #c/user to
> change the owner of the process.

oops, sorry, missed it. Ignore me :-)

ron

Re: [9fans] Novice question - run as other

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

You're confusing name space and semantics.  It is indeed in the name space
but the semantics of writing it is to change the state of the writer not
everyone who can see the name space.  Processes owned by different
users can all share objects in the same name space.  However reading or
writing those objects can have different permissions and results for
the different processes.

If I where to unbind /dev, all processes in that name space
would see that object disappear.

The discontinuity/incongruity in Plan 9 is what an object can see
about the process using it.  Kernel objects (things implemented with #x
for any x) can see the process and can adjust their behavior
on its immediate state (this is especially true of #p).  However
anything that goes through 9P only sees the user's state by way of
the messages sent to it.  It can't tell anything about the particular
process performing an action and can thus only adjust its semantics
according to the user who actually bound the object into its
name space (this action turns to an attach).

[-- Attachment #2: Type: message/rfc822, Size: 3102 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Novice question - run as other
Date: Wed, 17 Mar 2004 22:00:45 +0400 (AMT)
Message-ID: <200403171800.i2HI0jtq086906@adat.davidashen.net>

>
> >@{echo -n none > '#c/user' ; while() {sleep 1} }
>
> >succeeds but does not change the owner of the process. Why?
>
> well, seems it would be bad if all you had to do to change userid was 
> echo into '#c/user'
>
> So, starting from that, the why should be apparent.

The 'Why' was about a different issue.

The question was why the C program behaves differently than
the shell script.  The C program just writes to #c/user to
change the owner of the process.

The answer is that writing to #c/user is special
in the sense that although it is a part of namespace, it changes
the state of the process space, which is only apparent if you look
into the kernel source.

A more general conclusion is that for tasks where writing to
or reading from files reflects or affects process space, and not
name space, rc is not suitable and C code must be written.

I am now into the sources to understand which files in the namespace
are actually not in it, but in the process space.

David Tolpin
http://davidashen.net/

Re: [9fans] Novice question - run as other

[rog]

> A more general conclusion is that for tasks where writing to
> or reading from files reflects or affects process space, and not
> name space, rc is not suitable and C code must be written.

that's not necessarily the case - only for something that changes
something in the writing process that isn't inherited by child
processes.

quite a few devices use this hack, often for efficiency reasons.

ones i'm aware of include (aspects of) srv(3), ssl(3), tls(3), ip(3),
cap(3), fs(3), dup(3) and cons(3)

[9fans] unsuscribe

[Jose timofonic]

unsuscribe

___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es

Re: [9fans] Novice question - run as other

[Russ Cox]

rog@vitanuova.com wrote:

>quite a few devices use this hack, often for efficiency reasons.
>
>ones i'm aware of include (aspects of) srv(3), ssl(3), tls(3), ip(3),
>cap(3), fs(3), dup(3) and cons(3)
>  
>

ip(3) ?

russ

Re: [9fans] Novice question - run as other

[rog]

> ip(3) ?

bind ether path

Re: [9fans] Novice question - run as other

[Martin C.Atkins]

On Wed, 17 Mar 2004 22:00:45 +0400 (AMT) David Tolpin <dvd@davidashen.net> wrote:
> A more general conclusion is that for tasks where writing to
> or reading from files reflects or affects process space, and not
> name space, rc is not suitable and C code must be written.

Is it the process that writes to the device that gets altered,
or the process that opens the device?

I suspect the former, but why is it not the second? If it was the second,
then rc could probably be used, but what else wouldn't work, or would break?

Was the choice one of expediency, or is there a real semantic advantage
to the first choice?

Martin

-- 
Martin C. Atkins			martin@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

[9fans] unsuscribe

[root]

unsuscribe

Re: [9fans] unsuscribe

[Jason Catena]

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

On Mon, Jul 27, 2009 at 14:36, root wrote:

> unsuscribe
>
>
I guess Unix isn't interested in Plan 9 anymore.
Jason Catena

[-- Attachment #2: Type: text/html, Size: 342 bytes --]

Re: [9fans] unsuscribe

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

On Mon, Jul 27, 2009 at 1:15 PM, Jason Catena <jason.catena@gmail.com>wrote:

> On Mon, Jul 27, 2009 at 14:36, root wrote:
>
>> unsuscribe
>>
>>
> I guess Unix isn't interested in Plan 9 anymore.
> Jason Catena
>
>
It doesn't understand these youngins...

[-- Attachment #2: Type: text/html, Size: 712 bytes --]

Re: [9fans] unsuscribe

[J.R. Mauro]

On Mon, Jul 27, 2009 at 4:32 PM, David Leimbach<leimy2k@gmail.com> wrote:
>
>
> On Mon, Jul 27, 2009 at 1:15 PM, Jason Catena <jason.catena@gmail.com>
> wrote:
>>
>> On Mon, Jul 27, 2009 at 14:36, root wrote:
>>>
>>> unsuscribe
>>>
>>
>> I guess Unix isn't interested in Plan 9 anymore.
>> Jason Catena
>>
>
> It doesn't understand these youngins...

It's jealous because Plan 9 is slimmer and prettier.

Re: [9fans] unsuscribe

[Jason Catena]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

And gets all the cleverest guys.  Sometimes they're a bit full of
themselves, and they don't cruise the highways normally (they'd rather
teleport), but they know all the neatest party tricks.

[-- Attachment #2: Type: text/html, Size: 213 bytes --]

Re: [9fans] unsuscribe

[andrey mirtchovski]

sing to this tune: http://www.youtube.com/watch?v=FVo_Y2wZ0Tw

♪♪♪ Root is the loneliest user in the Plan 9 world
Eve can be as bad as root, it's the loneliest user since the user Root...♪♪♪

on a second thought, don't. it is a silly song.

Re: [9fans] unsuscribe

[Federico G. Benavento]

"This video is not available in your country due to copyright restrictions."

On Tue, Jul 28, 2009 at 2:26 AM, andrey
mirtchovski<mirtchovski@gmail.com> wrote:
> sing to this tune: http://www.youtube.com/watch?v=FVo_Y2wZ0Tw
>
> ♪♪♪ Root is the loneliest user in the Plan 9 world
> Eve can be as bad as root, it's the loneliest user since the user Root...♪♪♪
>
> on a second thought, don't. it is a silly song.
>
>



-- 
Federico G. Benavento

Re: [9fans] unsuscribe

[Ethan Grammatikidis]

On Tue, 28 Jul 2009 02:59:19 -0300
"Federico G. Benavento" <benavento@gmail.com> wrote:

> "This video is not available in your country due to copyright restrictions."

Odd that. Search for _One Is the Loneliest Number_ by _Three Dog Night_ if you want to hear it. It's a bit of a classic.

> 
> On Tue, Jul 28, 2009 at 2:26 AM, andrey
> mirtchovski<mirtchovski@gmail.com> wrote:
> > sing to this tune: http://www.youtube.com/watch?v=FVo_Y2wZ0Tw
> >
> > ♪♪♪ Root is the loneliest user in the Plan 9 world
> > Eve can be as bad as root, it's the loneliest user since the user Root...♪♪♪
> >
> > on a second thought, don't. it is a silly song.
> >
> >
> 
> 
> 
> -- 
> Federico G. Benavento
> 


-- 
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] unsuscribe

[Skip Tavakkolian]

> On Mon, Jul 27, 2009 at 4:32 PM, David Leimbach<leimy2k@gmail.com> wrote:
>>
>>
>> On Mon, Jul 27, 2009 at 1:15 PM, Jason Catena <jason.catena@gmail.com>
>> wrote:
>>>
>>> On Mon, Jul 27, 2009 at 14:36, root wrote:
>>>>
>>>> unsuscribe
>>>>
>>>
>>> I guess Unix isn't interested in Plan 9 anymore.
>>> Jason Catena
>>>
>>
>> It doesn't understand these youngins...
>
> It's jealous because Plan 9 is slimmer and prettier.

eunuches aren't attracted to glenda.

[9fans] unsuscribe

[Luciano Hillcoat]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

unsuscribe

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T88ad5b26ba9eae73-M195e82c7b1f7a5615d5b84c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 693 bytes --]