9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <200403171800.i2HI0jtq086906@adat.davidashen.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0403171003040.23850-100000@maxroach.lanl.gov>

>
> >@{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/


  parent reply	other threads:[~2004-03-17 18:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-17 12:43 David Presotto
2004-03-17 17:03 ` ron minnich
2004-03-17 17:13   ` rog
2004-03-17 17:13     ` David Presotto
2004-03-17 18:00   ` David Tolpin [this message]
2004-03-17 18:12     ` ron minnich
2004-03-17 18:14     ` David Presotto
2004-03-17 19:34     ` rog
2004-03-17 19:43       ` [9fans] unsuscribe Jose timofonic
2004-03-17 19:52       ` [9fans] Novice question - run as other Russ Cox
2004-03-17 19:58         ` rog
2004-03-18  4:21     ` Martin C.Atkins
  -- strict thread matches above, loose matches on Subject: below --
2004-03-17 18:29 plan9fans
     [not found] <200403170948.i2H9mi3W084127@adat.davidashen.net>
2004-03-17 18:24 ` 9nut
2004-03-18  7:38   ` boyd, rounin
     [not found] <200403161953.i2GJrNMv080779@adat.davidashen.net>
2004-03-16 22:54 ` 9nut
2004-03-17  7:18   ` David Tolpin
2004-03-17  8:10     ` Geoff Collyer
2004-03-17  8:24       ` David Tolpin
2004-03-17  8:55         ` Geoff Collyer
2004-03-17  9:04           ` David Tolpin
2004-03-17  9:19           ` Bruce Ellis
2004-03-17 10:31           ` boyd, rounin
2004-03-17 14:01             ` Dave Lukes
2004-03-17  9:33     ` 9nut
2004-03-17  8:54       ` David Tolpin
2004-03-17  8:56         ` Charles Forsyth
2004-03-17  9:07           ` David Tolpin
2004-03-17  9:17             ` Charles Forsyth
2004-03-17  9:28               ` David Tolpin
2004-03-17 10:08         ` 9nut

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=200403171800.i2HI0jtq086906@adat.davidashen.net \
    --to=dvd@davidashen.net \
    --cc=9fans@cse.psu.edu \
    /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;
as well as URLs for NNTP newsgroup(s).