In Unix, is it possible to login as a user who hasn't been assigned a password?

If I create a new user in Unix and don't give them a password, is it possible for them to login? I've tried logging in as them and just leaving the password field blank, but that doesn't work. I just want to make sure that there aren't any backdoors that I don't know about.

Also, what about the daemons and other users like nobody, are they assigned a password when they are created? Is it possible to log-in as any of them?

Nobody is a group, not a user account. So to answer your question, no you cannot login as a group. As far as daemons, it varies. You cannot login as user sendmail. However, you may be able to login some systems (insecure ones..) as uucp and similar.

are you sure that nobody is not a user? I'm pretty sure that apache runs as user nobody in group nobody, and my proxy directory is listed as being owned by nobody and in group nobody

i think we need freebsd (the devshed poster, not the os) on this one, he|she seems to be quite the unix guru

>>If I create a new user in Unix and don't give them a password, is it possible for them to login?

No.

>>what about the daemons and other users like nobody, are they assigned a password when they are created?

No. daemon is known to be system user WITHOUT a shell while nobody is also a system user, but the unprivileged one and without a shell as well.

>>Is it possible to log-in as any of them?

Yes so long as one has a shell and a password but a home directory is not required. Without a home directory, the "default root" for such user is /.

>>my proxy directory is listed as being owned by nobody and in group nobody

Then user nobody has privilege to rwx to your proxy directory. For all other directories, let's say it's owned by root and belong to root group, then the permission for this directory needs to be 777 in order for user "nobody" to write to or create new file to.

It's extremely insecure to allow any system users or super user (root) to login directly, all bad things can happen.

Jump to your request if you insist to enable "nobody" to login via telnet:
1) Assign a shell to user "nobody". As root, run "chsh nobody", and give "nobody" a valid shell.
2) Issue nobody a password. As root, run "passwd nobody" and give "nobody" a password.

To enable ftp login, comment out the user "nobody" in your /etc/ftpusers file.

Much thanks freebsd, that was just the information I was looking for. I actually wasn't looking to login in as nobody, but rather make sure that no one else can log in as nobody.

What I'm trying to do is have a directory that I can access, apache can access (to use as includes in PHP scripts) and no one else can read. So I was going to set the user to me, the group to nobody, and the permissions to 750.

Will this be secure as I think it will? Or is there a better solution?

One thing I just thought of is that other users on the system could probably just include the same file in their PHP script and print out the values (sensitive stuff like usernames and passwords) because the directory group is nobody. Hmm, there's gotta be a better solution.

You gonna have to read through http://www.apache.org/docs/suexec.html and disable telnet access for your users and use proftpd.

yikes, so i guess what you're saying is that a multi-user environment (all with telnet access) with files that need to be secure and readable by the webserver is simply not possible? and also that my idea of setting the group to nobody would not work?

so i guess people who store sensitive information on their webserver are simply the only users on that server?

[This message has been edited by RyanP (edited September 19, 2000).]

>>my idea of setting the group to nobody would not work?

Right.

>>so i guess people who store sensitive information on their webserver are simply the only users on that server?

Better be unless you use SuEXEC. So no clear text password should be stored anywhere on the server.

freebsd, I read the apache suEXEC page and that sounds great for accessing a file otherwise inaccessible to the webserver

but wouldn't the accessed file just have a plaintext password in it? is there a way to store encrypted passwords and somehow automatically decrypt them for use in scripts that need the password to access a database program?

i would think that many, many people would be faced with this situation, what do they do to solve this problem? i have searched endlessly for the "standard" solution, but have yet to find one

>>wouldn't the accessed file just have a plaintext password in it?

You can then have plaintext password as others won't be able to read it.

>>to store encrypted passwords and somehow
automatically decrypt them

No. It's one-way encryption. Many PHP scripts that have access to MySQL and with clear-text password and username in it are opening a big security hole not to public, but to everyone on the same server. Everyone can retrieve the clear-text password in PHP scripts of others on the same server.

For SuEXEC, the script is executed under the unique userid, so such script can retrieve the clear-text password and assign a $password, then securely access to db. Other scripts from other users on the same server can't do the same because their script won't have the permission.

To test it yourself, you can run apache as root and root group.