Are login screens only for physical security? Im not too concerned with physical security, but if the login screen plays a role in seperating user functions (i.e. 1 user for browsing, 1 for shopping etc) of my various users accounts than im all for it. I DID notice every user has their own application configurations when logging in through the login screen..

The login screen is just a place to log into user accounts or root (don't do that). I have a user account for browsing and games and a user account for shopping/bills. I prefer to login at a console command prompt and receive my daily fortune.

Thanks for the response, I would use the command prompt to change users but I dont think the environment/shell variables would be set accordenly for each user, if I do it this way (until I learn how to properly set those up myself atleast) So I guess I should just stick with the login screen which i'm assuming does configure these variables automatically (atleast to some extent)? Or would su - solve all my concerns invloving variables? I prefer not to always have type in my password just to login as it's a drag...

You either have a GUI login box that pops up or you have a console. In either case, you enter (or click) you login account name and enter your password (click) or at the console prompt.

Either one is as good as the other but if you use the console you'll have to type the user id and password and then startx (the GUI box does that for you).

You may deeply hate having to type a password to log in but that mechanism is there to protect you -- not just for physical reasons, like the janitor logging in to your account in the middle of the night. The login is your first line of defense against intruders, and, if it is only you that uses the machine in a secure environment, you're still are bettor off accepting the extremely short standard login and password -- train yourself to do it and you'll never regret it.

And, for heaven's sake, do not activate the administrative accounts (the ones listed after root in /etc/passwd -- they should never have an active password.

I'm not entirely sure I get what you are asking. The login screen is just an interface that allows you to log with a particular username and desktop environment. Its a front end for the command prompt stuff. The main configuration, libraries, and programs are in / (which is Su's domain). The home directory has configuration files in hidden folders /home/usrname/.foldername (like %APPDATA% in Windows) for each user. Its like windows where all the files are installed in C:/ but there is a folder called Users (like home) where people have their own accounts, settings, and documents.

Slackware loads up to a command prompt (I can easily change that to a login gui screen). I use xwmconfig to change window manager per a user and it sticks for that user with each one having its own unique setup but sharing the libraries and programs in /. That can be easily changed though with group permissions.

Here is stuff about login managers.
https://wiki.archlinux.org/index.php/Display_manager

The login password would have to be my user's password so it has to be complex nevertheless imo. But im taking it is purely for a physical restriction, but if you can provide an example on how a user account without a login screen may be more seceptible from an intrution by someone far away, that would be great.

Lol I know, im actually looking for more that can be blocked..

Thanks its just that when I use the GUI login box I notice that the firefox settings for each user is different (on Linux Mint). Not really different but like the user accounts who's firefox settings I did not change still have their default firefox settings (not saying this bad). This led me to believe that these login boxes are doing something with configurations (like seperating some type of config file for each user). So im wondering, do these login boxes only have an impact on app config settings, or do they also alter the folders like you mentioned aswell?

Stop.

1. an authorized login is defined by having an identity (the login name), and authentication key (the password), a valid storage area (the home directory), and a valid command interpreter (various choices).

2. A login window provided by a session manager doesn't change anything about #1. It is just a different method to login

3. The users home directory provides the storage of any configuration files they want. By default these are usually initially created when the login account is created (copied from a skeleton definition in /etc/skel). GUI programs will usually create default files if they need one, and the user hasn't created or modified those.

The login process itself need not be complex - though it does have to have the privilege level necessary to start a user environment. The usual steps are to request a login identity, and an authentication.

Once the password is entered it is hashed using a method defined by the system administrator (or a default defined by the distribution). The resulting hash is compaired against the stored version in the /etc/shadow file. If they match (and no exceptions defined in the /etc/shadow prevent it), the login program can then set the working directory of the login process to that of the users home directory (as specified in the /etc/passwd file). If that directory doesn't exist most (not all) login processes will abort.

Once the home directory has been validated the login process can change its UID and the GID lists to that of the user. This is a one-way transition from a privileged mode to a users unprivileged mode. In some cases the login process will impose user limits just before that transition (/etc/security).

When that completes without errors, the process (now running as the user) can either start the GUI desktop the user has previously used or specified - or use a default desktop...

If the login is without the GUI, then the defined users shell is started designated as an interactive shell. The shell program will then load any environment definitions (/etc/profile, .profile, .loginrc, ...) as defined by the specific shell.

In the case of logging in to console terminal, the console terminal is first initialized by the getty/agetty program. This is derived from a serial line login from ages past - it sets things like baud rate, number bits for a character, parity handling, modem handling and such. Once it has done these then it will prompt for a users login identity.

Once that identity is entered then the "login" application is invoked, recieving the identity and prompts for the users password.

The GUI session manager provides the same service that the getty/agetty programs do. It sets up the keyboard/mouse/display for a login. Frequently it also includes the login utility - but it isn't mandatory. The actual login window used can be a separate utility that functions in the same way the login tool does. The only difference is it starts a GUI desktop instead of the users command interpreter.

2 members found this post helpful.

That is because each user account is a clean install in regard to settings from the defaults.

Here is a tutorial related to hidden configuration files in home directory:
http://www.howtogeek.com/194342/how-...uration-files/

Here is an explanation of the linux filesystem (check etc, usr, and home descriptions particularly):
http://linuxnewbieguide.org/overview...filing-system/

There is a .mozilla directory in every user home directory that has started Firefox (it does not exist until the first use of Firefox or Seamonkey).

You can see the directories in a user's home directory with
When a user configures Firefox or Seamonkey for his/her preferences, the content of those directories will be changed, reflecting the choices made; e.g., home directory, font, bookmarks and so on.

That's how individual users can do what they want.

The login sequence (no matter how) does not in any way affect Firefox.

1 members found this post helpful.

Obviously lol, I apologize I made it sound like an oxymoron.. I was wondering how each user was able to hold seperate Firefox configuration settings in the first place. Which I now understand.. When a user is created his default settings gets copied over from /etc/skel, then say I change a user's firefox browser settings, he's able to retain this seperate configuration setting in .mozilla (which the GUI program Firefox created, I think) which is in his personal home directory... Thank you Jpollard for the in-depth explanation, Tronayne, and RadicalDreamer!

1 members found this post helpful.

I take it this is why /etc/passwd needs read permsissions for others? When I tried to modify /etc/passwd with chmod o-r I couldnt login anymore... (I dont want others to see whats in this diectory...)

World read is normal. What it provides is the ability to read and map UIDs (and home directories) back to the users name. Without that errors occur, and that becomes an authorization error.

To prevent users from seeing what is in the users home directory, remove group and world access to the directory itself.

Yep I thought so that explains it.. I already knew to keep home directory's permissions permitted only to the owner, but I wanted to retrict permissions of the /etc/passwd so peopls cant see the list of user accounts. I can atleast chmod go-r for the /etc/group directory... Thanks again!

You need to stop for a while and think things through -- by default the permissions on /etc/passwd are these:
That is, the owner, root, has read-write, group and public have read-only. It's supposed to be that way for reasons listed in a previous post.

Basically, the message is, quit screwing around with it before you break something.

If you look at man 5 passwd you'll see (among other things)
Note that the optional encrypted password field should never, ever, under any circumstances should be used (read all the manual page).

All user passwords are kept in /etc/shadow. You can look at 'em:
Do not, under any circumstances, screw around with them or try to take them apart (or, particularly, place passwords on the accounts that do not have them by default which would make them able to be logged in, you do not want to do that).

The fields in /etc/shadow are separated by colons, as are the fields in /etc/passwd, you do not manually add anything to those fields; in fact, don't even look at them because there is nothing you ever need to do with them, leave the dang things alone.

Note that the permissions on /etc/shadow are
That is, root has read-write, group has read (the group is shadow) and nobody else can even see the file content.

Back to /etc/passwd.

About the only thing you ever want to do with it is when you add a user account: name, automatic-generated user ID (the number) automatic group ID (the number) and the default shell program -- which is, most likely, to be /bin/bash. You may have users that prefer another default shell; e.g., KornShell (ksh), C-Shell (csh) among others.

You may need to add additional group IDs to a user or users and you do that with groupmod (after carefully reading the manual page for the utility). Note that, if you're adding users to a group that the group name must exist in /etc/passwd to be effective.

This is hard on purpose. Only the administrator (root) has access to the utilities that manipulate /etc/passwd, /etc/group and, particularly, /etc/shadow. You do not ever edit those by hand, you do not ever edit /etc/shadow (forget that it even exists), learn the utilities that are used to make additions and changes.

Never, under any circumstances, allow a user to gain root access with sudo, only you should have root access, only you should know the root password ("you" here can be one individual or other administrators if you have them).

Your original question about a GUI or console login is simply answered: it does not matter.

Hope this helps some.