Date: Tue, 29 Jun 1999 02:20:15 +0200 From: Pierre Beyssac <pb@fasterix.freenix.org> To: Dag-Erling Smorgrav <des@flood.ping.uio.no>, Pierre Beyssac <beyssac@enst.fr> Cc: Pierre Beyssac <pb@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/vipw pw_util.c vipw.c Message-ID: <19990629022015.B733@fasterix.frmug.fr.net> In-Reply-To: <xzpd7yf2969.fsf@flood.ping.uio.no>; from Dag-Erling Smorgrav on Tue, Jun 29, 1999 at 01:32:30AM %2B0200 References: <199906261215.FAA18022@freefall.freebsd.org> <xzpogi01e8n.fsf@flood.ping.uio.no> <19990628193311.A63701@enst.fr> <xzpd7yf2969.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 29, 1999 at 01:32:30AM +0200, Dag-Erling Smorgrav wrote:
> > I disagree; the umask 077 is on purpose because we're dealing with
> > the password file, not just any random use of $EDITOR.
>
> I believe you don't quite understand the code. What happens is:
And I believe you haven't read the PR this was intended to be a
fix for. Otherwise you would have immediately understood what I
was refering to by "we're dealing with the password file".
> Now there are two instances in which the second call to umask(2) has
> any effect at all:
>
> 1) you use a losing editor which creates backup files with
> permissions different from those of the file you're editing.
We all agree this doesn't need to be considered. I'd phrase it a
bit differently though (s/different from/less restrictive than/).
> 2) while editing the password file, you create and edit another file.
Or make a partial write: that was the object of the PR. Remember
that the editor is started on a copy of the master password file.
Any partial write of this shouldn't be readable by anyone else but
root.
> The solution to the first case should be obvious to everyone. As for
> the second case, it is my humble opinion that we should restore the
> original umask, if only in the name of POLA.
I assumed that it was a good opportunity to prevent people from
shooting themselves in the foot. It always seems better to be on
the safe side.
But I really don't feel a need to argue at length about this; so
if there's a general consensus that the patch is wrong, let's change
the patch.
> The second call to umask(2) does not in any way affect the file mode
> of either master.passwd or the temp file used for editing it.
Quite right. You forgot to mention it doesn't affect the subsequent
fork/exec to pwd_mkdb either, because pwd_mkdb sets the umask to
0 itself.
--
Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org
{Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990629022015.B733>