spicyfish / freenos

Automatically exported from code.google.com/p/freenos
GNU General Public License v3.0
0 stars 0 forks source link

Implement a login program #59

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
It is very useful to have a login program which can read
for example /etc/passwd, and prompts for a username. It should
launch a shell when a valid username has been entered as that user.

We could use libparse to interpret /etc/passwd, using ':'
as the field separator. Also, the init process should eventually
run the login program once the system has fully started.

Original issue reported on code.google.com by coenbijlsma on 7 Aug 2009 at 11:38

GoogleCodeExporter commented 9 years ago
It wouldn't be necessary to implement kludges from the 1970's, right? I'm not 
saying 
you folks should implement LDAP from day one, but be sure to keep the API and 
the 
actual file format/lookup code separated. Modern operating systems like OS X 
have their 
own custom directory service. OS X uses XML files to store local users, which 
means 
programs can store additional information, such as passwords hashed using 
multiple 
algorithms, etc.

Original comment by edschou...@gmail.com on 11 Aug 2009 at 7:06

GoogleCodeExporter commented 9 years ago
I agree with Ed. We shouldn't just reimplement a /etc/passwd blindly. I was 
thinking
to store it in separate files in /etc/user, like this:

 /etc/user/$USERNAME/{home | password | uid | gid | realname}

That way, /bin/passwd does not need to be a setuid program -- the user simply 
has
write permissions to /etc/user/$USERNAME/password (but not for other users 
ofcourse).

It's just a proposal ofcourse. XML may have it's advantages aswell.

Original comment by nieklinn...@gmail.com on 11 Aug 2009 at 8:37

GoogleCodeExporter commented 9 years ago
Well, I don't know if it's a good thing if a user can see its own password 
hash... If 
he/she would only be able to validate against the password (using a setuid 
helper, 
invoked by a library function or something), it would be a lot more secure.

Original comment by edschou...@gmail.com on 11 Aug 2009 at 8:39

GoogleCodeExporter commented 9 years ago
Some reasoning behind this:

- You want users to be able to authenticate to be able to change their own 
password.
- Malicious processes running as a specific user could obtain the hash and send 
it to an 
attacker. The attacker is then able to perform local dictionary attacks on the 
hash, 
making it easier to obtain the corresponding password.

Original comment by edschou...@gmail.com on 11 Aug 2009 at 8:41

GoogleCodeExporter commented 9 years ago
I agree, you are right. Perhaps we should let an authentication server do the 
job.

Original comment by nieklinn...@gmail.com on 11 Aug 2009 at 8:45