l4-hurd
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]