Can new user inherit settings by other?

[Slavi]

I installed Kali linux and while i was running as root I installed quite some programs and made graphical changes etc, even changed desktop environment .. then made a new user so I won't be using root and the new user has all the default stuff and no access to anything I did in the root session .. is there any way to ..um .. maybe use root's session without the previliges until password is entered? :s

[Hiroshe]

I'm not familiar with Kali, and I winged the entire thing without testing. Here goes.

As root:

# Create the users home directory.
mkdir /home/<username>

# Copy home over from root.
cp -r /root/* /home/<username>

# Create the account.
useradd <username> -d /home/<username>
passwd <username>

# Set default permissions.
chown -R <username> /home/<username>
chgrp -R users /home/<username>
chmod -R 600 /home/<username>

# Fix some other permissions.
chmod -R 700 /home/<username>/bin
chmod 700 /home/<username>/.bash_profile
chmod 700 /home/<username>/.bachrc

Also, by default, new home directories (created when -d isn't specified) are copies of /etc/skel. You could also change whats in there if you want something more automatic.

[Slavi]

Just a quick question before I try it .. that means all settings and graphical changes/desktop effects will be the same right?

Also THANKS for the detailed commands and explanation

[rubberman]

Some settings are universal and others are personal. When as root you set up some GUI configurations, many of those are "global", so you get them as a normal user. As for your question "is there any way to ..um .. maybe use root's session without the previliges until password is entered?" - you really, really do not want to do that! It would leave your system very open to security exploits.

So, please explain why, exactly, you want to do this?

[Slavi]

Thats why I don't want to use it as root. Currently the only existing user is root and I want to create another one that has sudo group and can add/remove programs after entering password. However while running in root I spent like 2 days configuring my desktop and installing programs, then realized it was root user. So in order to protect my system I want to make antoher user but still use whatever is already installed. I wrote the thread after I made another user and all the settings are brought to default on that(Not taking after what was done by root)

[Hiroshe]

Just a quick question before I try it .. that means all settings and graphical changes/desktop effects will be the same right?

In general, yes. If all your changes were made in your home directory, then it will copy them all over. Even if you made a change outside your home directory (something that I very rarely recommned), those changes should be applied to all users.

An exception might be if you run some root command in your .bash_profile for example. Then obviously those commands do not have the rights to run.

Just give it a try. The worst that can happen is that you need to remove the new user.

[Slavi]

Fix some other permissions.

chmod -R 700 /home/<username>/bin
chmod 700 /home/<username>/.bash_profile
chmod 700 /home/<username>/.bachrc

Those file's dont exist in the newly created folder, its just copy of root(Which is basically the "home" for root user so it has Downloads/Documets etc)

I did the steps until then, when I try to log into the newly created account it just takes me back to log in screen

[Hiroshe]

It's ok if they don't exist. Set these permissions if they happen to exist.

Start over with:

userdel <username>
rm -rf /home/<username>

Do everything a I sad before, except:
Use chmod -R 744 /home/<username> instead of chmod -R 600 /home/<username> and don't run anything from lines 16 to 19.

Also, what Window manager/Login manager are you using? Is it Gnome/GDM?

[Slavi]

yeah its gnome by default, will try using that permission instead when I get home, thanks

[Slavi]

Hey, I just tried it and all programs and files are available to the new user! Is there any way to move desktop environment and desktop effects or just set it again? Thanks by the way, much =)

[Slavi]

^Also shotcut keys? :p

[Hiroshe]

Just be carefull. That chmod 744 command made everything executable. That means if you had any malicious programs in your admin account that didn't have execute permissions, now they do.

You probably don't need to worry about this, but it might be good practice to run chmod 644 -R /home/<username> and then run lines 17 to 19 with the number 644 instead of 700. I think the problem was the 00 the end of the permissions.

I think the problem with the shortcuts and desktop effects was that it didn't copy over all of the hidden files. Try copying them over with cp -r /root/. /home/<new_user> instead. After doing that, you'll need to chown, chgrp and chmod again.

[Slavi]

Okay I'll try it and get back :) Um, about malicious software, I just reinstalled everything completely so should be safe for now

Edit: When I used copy the root folder root/* with the star afterwards, doesnt that mean it would include hidden files too? At least I thoguht so

[Hiroshe]

Okay I'll try it and get back :) Um, about malicious software, I just reinstalled everything completely so should be safe for now

Yes, it's just practice.

When I used copy the root folder root/* with the star afterwards, doesnt that mean it would include hidden files too? At least I thoguht so

I just ran a few tests on cygwin. It looks like the command cp -r /root /home/<username> works, without any *'s.

--

cp -r /root/* /home/<username> doesn't copy hidden files, because globbing in bash ignores hidden files by default (whoops). Though, if you wanted to use globbing, you could set dotglob in bash. Though at that point you should probably be using find and xargs find /root/ -regex '/root/.*' | xargs cp -t /home/<username>.

[Slavi]

I used cp -r /root/. /home/<username> and it did copy all hidden hiles. I am now in the new user and everything works great. The only thing I didn't do was lines 17-19 because the files don't exist. Um, Another thing is when I type in terminal usually it shows <username>@pcName$ now it only shows $ and it doesn't auto complete directories using tab. I wonder if some of that was caused because I ran the new user before moving the hidden files?

[Hiroshe]

It's probably because your .bash_profile and your .bashrc don't have execute permissions. These files most likely exist. Run:

chmod 744 /home/<username>/.bash_profile
chmod 744 /home/<username>/.bachrc

cp should have overwitten the default .bash_profile and .bashrc automatically, so you should be ok.

[Slavi]

don't have .bash_profile in root i got .bash_history , but I have .bashrc. Should I run only on bashrc? Also in the previous post you said 644 instead of 700, now 744, should I use 744 as last?

[Slavi]

oh I have .profile I guess this is the one we need. Running the commands now :)

EDIT: Um, no change terminal only shows $ and tab is just spaces. If I delete the user and remake everything again do you recon it would change something?

[Hiroshe]

Ok, "744" means you may read, write and execute, while others may only read.
"644" read and write, while others may only read.

.bashrc and .bash_profile (if it exists), as well as .profile (if it exists) need to be marked as executable. You shouldn't mark everything in your directory as executable though (which is different from what you might be used to on windows).

Before I was being paranoid, saying that others cannot read the files "00". It mgiht have caused gnome some greif though.

So, everything should be 644 by default, except for .profile, .bash_profile and .bashrc if they exist (in your case .bash_profile doesn't exist, but the others so, so set them). They should be 744.

The fact that the terminal is just showing "$" and no autocomplete means that .bashrc/.bash_profile/.profile are not running.

You can try to redo everything again (only 6 commands or so).

[Hiroshe]

Here's another thing you can do:

type in ls -Ral /home/<username> > in_user.txt and then type in ls -Ral /root > in_root.txt.

This will make 2 text files. In in_user.txt there will be a list of all the files in the users accound, and on the left, you'll see the permissions (the textual meaning of that 744 stuff). Same goes for in_root.txt. Now you can compair which permissions are different/which files are missing, and set them yourself.

To understand how permissions work, refer to http://en.wikipedia.org/wiki/File_system_permissions#Symbolic_notation . And the numeric notation section.

[Slavi]

Okay so what I did step by step ..

Create the users home directory.

mkdir /home/<username>

Copy home over from root.

cp -r /root/* /home/<username>
cp -root/. /home/<username>

Create the account.

useradd <username> -d /home/<username>
passwd <username>

Set default permissions.

chown -R <username> /home/<username>
chgrp -R users /home/<username>
chmod -R 744 /home/<username>

Fix some other permissions.

chmod 700 /home/<username>/.profile
chmod 700 /home/<username>/.bashrc

This resulted in exactly the same state as before, in terminal the only thing that appears is the dollar sign and tab doesn't auto complete location/folder/file names. I can get the text files with permissions but its a bit weird since i am not sure if permissions are the problem now, everything else seems to be working normally

[Slavi]

Okay, I did some google digging, it might come down to the permission for /bin . I found in some other forums people say

make sure you are using /bin/bash instead of /bin/sh as your shell
Using /bin/bash fixed this issue for me.

My problem now I guess is that I don't have a bin folder in the new user?

I do have a bin folder in my File System, and the first file it in is bash. Is that what they are referring to?

[Hiroshe]

cp -r /root/* /home/<username>
cp -root/. /home/<username>

Just use cp -r /root /home/<username>. The first command won't copy over the hidden files, and the second command is misspelled.

chown -R <username> /home/<username>
chgrp -R users /home/<username>
chmod -R 744 /home/<username>

The problem with that is that everything is executable. If you don't care that everything is executable, then whatever. I would suggest 644 though, then set only files that need to be executable as 744 (which in your case is just .bashrc and .profile).

chmod 700 /home/<username>/.profile
chmod 700 /home/<username>/.bashrc

You've already set the executable bit with the last command. Why are you doing it again?

make sure you are using /bin/bash instead of /bin/sh as your shell

Oh, I thought you were already starting up with bash. If you want to change it to bash: chsh -s /bin/bash <udername> should work.

Keep in mind /bin/ is in the root directory, and it is not the same as a users personal /home/*/bin directory. Do not change any permissions in /bin/ (or even touch that folder) unless you know what your doing, and what all of the permissions mean.

[Slavi]

chsh requires the pw of the user, when typed it returns authentication failed. Tried with root pw as well still says authentication failed.

so if using chmod -R 744 /home/<username> then I dont need 17-19? Also, I used 744 here as suggested on one of the posts earlier.

but yeah from what I've seen digging in google chsh seems to be what might be the main concern for the problem right now. I tried it 2 days ago as well as i asked a friend and he said exactly that but even then it was failing to authenticate me

[Slavi]

Okay found solution to that incase any1 ever reads that here

[Slavi]

That fixed it all! It's working great! Thanks for your time and help Hiroshe, much appreciated!!

Should I redo everything and use chmod -R 644 /home/<username> and skip 17-19? A bit confused on this as after you said
You've already set the executable bit with the last command. Why are you doing it again?

And, should the new user have permissions to access root folder and such? Because currently it has

Also, sudo apt-get update returns
<username>is not in the sudoers file. This incident will be reported

[Slavi]

Added to sudo group now using adduser <username> sudo

[Hiroshe]

Should I redo everything and use chmod -R 644 /home/<username> and skip 17-19? A bit confused on this as after you said

Let me put it this way. You want everything to be 644 by default, except for .bash_profile, .bachrc, .profile and /home/*/bin/*. Those should be 744 if they exist.

So, set everything recursively to 644, then change the permissions of each of those files if they exist.

For example, you haven't setup a /home/*/bin, so it doesn't make sense to set the permissions on a folder that doesn't exist. But you do have a .bashrc, so set that to 744.

Should I redo everything and use chmod -R 644 /home/<username> and skip 17-19? A bit confused on this as after you said

I said that because you set the executable bits all all you files. Then you set it again for a few files. Those are just unproductive commands. Instead you should not set the executable bit, and then set it where you know it's needed.

And, should the new user have permissions to access root folder and such?

Yes, it needs permissions to read from /. That's how you are able to run programs and such.

Permissions work like this:
There are 4 numbers. The second one is the owners permissions. The the third one is the groups permissions. The forth one is the permissions for other users. The first one is for setuip, setgid and sticky bit, but it's often ommited, and let's not worry about that for now.

Execute is the value 1. Write is the value 2. Reads is the value 4. To get the final permissions, add them up.

So, if you want the user to be able to read, write and execute, while others can only read, then the permission would be:
1+2+4 = 7, 4, 4 = 0744 = 744.

The first number is for the setuid, setgid and the sticky bit. Setuid means that the program will be executed with the owners permissions (passwd might have a setuid for example). Setgid is the same except for groups. Sticky bit means that even if a user has read/write permissions to a folder, they don't automatically have read/write permissions to it's children (/tmp in multi-user environments might be an example).
1 is for sticky bit, 2 is for setgid and 4 is for setuid.

Now that you understand what these numbers means, you should be able to judge for yourself how you want to set up the permissions.