All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ragnar Kjørstad" <kernel@ragnark.vestdata.no>
To: Romano Giannetti <romano@dea.icai.upco.es>, linux-kernel@vger.kernel.org
Subject: Re: User-manageable sub-ids proposals
Date: Thu, 13 Dec 2001 19:58:57 +0100	[thread overview]
Message-ID: <20011213195856.A30952@vestdata.no> (raw)
In-Reply-To: <20011208155841.A56289@wobbly.melbourne.sgi.com> <3C127551.90305@namesys.com> <20011211134213.G70201@wobbly.melbourne.sgi.com> <5.1.0.14.2.20011211184721.04adc9d0@pop.cus.cam.ac.uk> <3C1678ED.8090805@namesys.com> <20011212204333.A4017@pimlott.ne.mediaone.net> <3C1873A2.1060702@namesys.com> <20011213113616.B6547@pern.dea.icai.upco.es> <20011213143752.A17124@vestdata.no> <20011213170629.A16572@pern.dea.icai.upco.es>
In-Reply-To: <20011213170629.A16572@pern.dea.icai.upco.es>; from romano@dea.icai.upco.es on Thu, Dec 13, 2001 at 05:06:29PM +0100

On Thu, Dec 13, 2001 at 05:06:29PM +0100, Romano Giannetti wrote:
> > 2 do we want the "slave" to be able to write the users files
> 
> Generally no, but you can create a dir where the slave uid can create file
> (think to a java applet that need temporary files, etc...) 

I think generally temporary files should go to /tmp and not the home
directory, but yes, there may be reasons to write to specific files in
the home directory as well.

> > This should also be possible to implement with minimal impact. All you
> > need is a new systemcall to allocate a uid for the slave. This means you
> > need to reserve some uids for this purpose, but with 32bit uids......
> 
> Yes, but then the slave process is very much _very_ limited. It could need
> to read/map dynamic libraries, for example; with my approach the slave uid
> processes are processes that have a full-level citizenship and that can do
> anything a process can do, but under a different name than the user. Root
> uses "nobody" to this extent sometime; my proposal is to extend this to
> every (unprivileged) user in a safe way. Then, you can create a chrooted
> environment for the new process and tailor the level of access it has
> depending on the needs.

Why would the slave not be able to read/map dynamic libraries in my
sceeme? Such files should be readable by everyone, so I don't see the
problem?

With ACL support I don't see this beeing limited at all. The process can
be given any rights you desire before changing it's effective userid.


-- 
Ragnar Kjørstad
Big Storage

  reply	other threads:[~2001-12-13 18:59 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05  3:32 [PATCH] Revised extended attributes interface Nathan Scott
2001-12-05  9:08 ` Anton Altaparmakov
2001-12-06  5:46   ` Nathan Scott
2001-12-06  3:05 ` Daniel Phillips
2001-12-06  5:41   ` Nathan Scott
2001-12-06 15:25     ` Daniel Phillips
2001-12-06 23:15       ` Nathan Scott
2001-12-07  1:45         ` Daniel Phillips
2001-12-07  2:03         ` Daniel Phillips
2001-12-07  3:51           ` Nathan Scott
2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08  4:58   ` Nathan Scott
2001-12-08 20:17     ` Hans Reiser
2001-12-11  2:42       ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
2001-12-11 12:02         ` Hans Reiser
2001-12-11 19:23         ` Anton Altaparmakov
2001-12-11 20:14           ` reiser4 (was Re: [PATCH] Revised extended attributesinterface) curtis
2001-12-11 21:34             ` Hans Reiser
2001-12-11 23:04               ` curtis
2001-12-11 23:28                 ` Hans Reiser
2001-12-11 23:46                   ` Anton Altaparmakov
2001-12-12  1:00                   ` curtis
2001-12-11 21:21           ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Hans Reiser
2001-12-11 23:33             ` Anton Altaparmakov
2001-12-11 23:59               ` Hans Reiser
2001-12-12  2:16                 ` Anton Altaparmakov
2001-12-12 12:02                   ` Hans Reiser
2001-12-12 13:34                   ` Anton Altaparmakov
2001-12-12 15:40                     ` Hans Reiser
2001-12-13  1:43             ` Andrew Pimlott
2001-12-13  9:23               ` Hans Reiser
2001-12-13 10:36                 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37                   ` Ragnar Kjørstad
2001-12-13 16:06                     ` Romano Giannetti
2001-12-13 18:58                       ` Ragnar Kjørstad [this message]
2001-12-18  0:17                     ` Pavel Machek
2001-12-13 23:24                   ` David Wagner
2001-12-21 21:28                   ` Andreas Ferber
2001-12-13 15:27                 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Andrew Pimlott
2001-12-13 20:47                   ` Hans Reiser
2001-12-13 21:01                 ` Anton Altaparmakov
2001-12-10 11:52     ` [PATCH] Revised extended attributes interface Stephen C. Tweedie
2001-12-10 15:00       ` Peter J. Braam
2001-12-10 15:56         ` Stephen C. Tweedie
2001-12-10 16:00           ` Mr. James W. Laferriere
2001-12-10 16:15             ` Stephen C. Tweedie
2001-12-10 19:01             ` John Stoffel
2001-12-11  1:22       ` Timothy Shimmin
2001-12-11 11:33         ` Stephen C. Tweedie
2001-12-11 13:30         ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11 14:34           ` Stephen C. Tweedie
2001-12-11 15:15           ` Anton Altaparmakov
2001-12-11  1:41       ` Nathan Scott
2001-12-11 13:47         ` Stephen C. Tweedie
2001-12-11 18:23           ` Hans Reiser
2001-12-11 18:46           ` Anton Altaparmakov
2001-12-11 23:37           ` Implementing POSIX ACLs - was " Nathan Scott
  -- strict thread matches above, loose matches on Subject: below --
2001-12-13 16:02 User-manageable sub-ids proposals Jacques Gelinas

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=20011213195856.A30952@vestdata.no \
    --to=kernel@ragnark.vestdata.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=romano@dea.icai.upco.es \
    /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.