[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design principles and ethics
From: |
Bas Wijnen |
Subject: |
Re: Design principles and ethics |
Date: |
Sun, 30 Apr 2006 22:49:26 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
On Sun, Apr 30, 2006 at 03:02:48PM -0400, Jonathan S. Shapiro wrote:
> > > In the absence of setiud, and assuming that parents get to inspect their
> > > children, how is /sbin/passwd protected?
> > >
> >
> > Not at all. It only accesses data the user is allowed to access. I
> > explained this in a former mail.
>
> Apparently I did not see it. Here is the essential question:
I suppose you missed my answer as well, because I already told this.
> /sbin/passwd requires the authority to write the password database,
> which the user does not have.
Correct.
> So: we must answer
> (1) how does /sbin/passwd come to hold this authority when the user does
> not?
It isn't a child of the user program. It is a system service which the user
can use. The user doesn't get full access to the program, because it isn't
the parent.
This is how it works in the current Hurd-on-Mach as well: there the
filesystem, not the user, is the parent of an activated translator (which is
the equivalent of a setuid application).
> (2) Given that the running instance of /sbin/passwd is a child of a
> program owned by the user,
It isn't a child of the user's program.
And by the way, also in the setuid case, it is /bin/passwd, not /sbin/passwd.
/sbin isn't in the user's default PATH, and so isn't a proper place for setuid
executables (which are meant to be run by normal users).
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
- Re: Design principles and ethics, (continued)
- Re: Design principles and ethics, Tom Bachmann, 2006/04/30
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/04/30
- Re: Design principles and ethics, Tom Bachmann, 2006/04/30
- Re: Design principles and ethics, Pierre THIERRY, 2006/04/30
- Re: Design principles and ethics, Marcus Brinkmann, 2006/04/30
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/04/30
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/04/30
- Re: Design principles and ethics, Marcus Brinkmann, 2006/04/30
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/04/30
- Re: Design principles and ethics, Marcus Brinkmann, 2006/04/30
- Re: Design principles and ethics,
Bas Wijnen <=
- Re: Design principles and ethics, Pierre THIERRY, 2006/04/30
- Re: Design principles and ethics, Tom Bachmann, 2006/04/30
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/04/30
- Re: Design principles and ethics, Marcus Brinkmann, 2006/04/30
- Physical access without ultimate power? (was Re: Design principles and ethics (was [...]))), Pierre THIERRY, 2006/04/30
- Re: Physical access without ultimate power? (was Re: Design principles and ethics (was [...]))), Bas Wijnen, 2006/04/30
- Re: Design principles and ethics (was Re: Execute without read (was [...])), Marcus Brinkmann, 2006/04/30
- Re: Design principles and ethics (was Re: Execute without read (was [...])), Marcus Brinkmann, 2006/04/30
- Re: the deadly hypercube of death, or: handling permissions, Jonathan S. Shapiro, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Marcus Brinkmann, 2006/04/27