Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!mel.dit.csiro.au!smart
From: smart@mel.dit.csiro.au (Robert Smart)
Newsgroups: comp.protocols.appletalk
Subject: Re: aufs security warning/fix
Message-ID: <1990Sep10.033135.9802@mel.dit.csiro.au>
Date: 10 Sep 90 03:31:35 GMT
References: <9009072101.AA15458@orchestra.ecn.purdue.edu> <3065@uakari.primate.wisc.edu>
Organization: CSIRO DIT (Melb.)
Lines: 35

In article <3065@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:
>
>Why is this an *aufs* problem?  If you have an account with no password,
>anyone can login to that account via modem, hardwired terminal, terminal
>server, telnet, ftp, etc. and have full access.  That's what "no password"
>means - it's a public account, essentially.
>
>Your password file is broken, not aufs.
>
Accounts without passwords are supposedly meant for specialized harmless
things. Some machines have an account sync which has /bin/sync in the
shell field.

The correct approach seems to be (a) there should be a standard
routine for checking a name/password combination; and (b) that
routine should check the shell field in /etc/passwd against a
list of interactive shells -- /etc/shells in SunOS 4.x. Usernames
with other shells there shouldn't get access except for the purpose of
running the named program.

The parameters to the access checking program would be username,
password and program to run. CAP could then call it like this:

	check_access(name,pwd,"AUFS")

and this would allow access if the password was empty and the shell
field for the user was AUFS. This would allow access to a sort of
anonymous AUFS account that had AUFS in the shell field. This
could be handy.

However given the number of things like CAP which assume that all
users in /etc/passwd are real users it is not a good idea to have
usernames like sync with no password and a supposedly harmless shell.

Bob Smart