You are not logged in.

#1 2016-05-15 13:53

chris_elvidge
Member
Registered: 2016-05-15
Posts: 17

su

When I 'su -' to get root in a terminal, I get what appears to be an rsync of various directories (.config, .gconf +others) owned by nobody:nogroup into roots directory. If I chown these to root:root, exit and su - again, they come back. What's happening?

Offline

#2 2016-05-15 16:14

Dai_trying
Member
From: UK
Registered: 2015-12-14
Posts: 2,992

Re: su

To get to root you should

sudo su

and that will give you a root terminal, what you are currently doing is issuing a command to be executed by root

Offline

#3 2016-05-15 16:47

chris_elvidge
Member
Registered: 2016-05-15
Posts: 17

Re: su

'sudo command' runs command as root from logged in user. 'su [newuser]' switches logged in user to newuser; without newuser switches user to root. 'su - [newuser]' starts a login shell; user assumes the user environment of the target [newuser]. I.e. runs /etc/profile, /etc/bash.bashrc, .profile (etc).
What I want to know is why it rsyncs several directories with the new environment.

Offline

#4 2016-05-15 16:58

chris_elvidge
Member
Registered: 2016-05-15
Posts: 17

Re: su

It's not an rsync, it's a tar job. Tested with a temporary user. Reports "tar: Cannot change ownership to uid 65534, gid 65534. Operation not permitted." But where does it get the source .tar file.

Offline

#5 2016-05-15 16:58

Dai_trying
Member
From: UK
Registered: 2015-12-14
Posts: 2,992

Re: su

I cannot reproduce this effect on my system, using "su -" just gives a root session.

Offline

#6 2016-05-15 17:00

Dai_trying
Member
From: UK
Registered: 2015-12-14
Posts: 2,992

Re: su

Could it be unpacking a skeleton for a new user?

Offline

#7 2016-05-15 17:03

chris_elvidge
Member
Registered: 2016-05-15
Posts: 17

Re: su

I'll try a reinstall/new install to check what happens. Nothing in /etc/skel. Cheers.

Offline

#8 2016-05-15 17:25

chris_elvidge
Member
Registered: 2016-05-15
Posts: 17

Re: su

Ah! Found what appears to be the culprit. /etc/profile.d/q4os_profile.sh runs the command 'tar -C $HOME -xf /usr/share/apps/q4os_system/q4home.tar' but is only supposed to run at first login. It seems that if the file $HOME/.trinity/share/config/kpersonalizerrc is missing it runs again. Obviously you see neither the untar (nor the errors if/when it can't change uid and gid to 65534) if it's hidden by the X environment. kpersonalizerrc only exists after running X and reads [General]/FirstLogin=False. Easy to fix now. Cheers.

Offline

#9 2016-05-15 18:37

Dai_trying
Member
From: UK
Registered: 2015-12-14
Posts: 2,992

Re: su

I'm glad you found the culprit, I don't think I would have smile

Offline

#10 2016-05-16 11:06

chris_elvidge
Member
Registered: 2016-05-15
Posts: 17

Re: su

Sorry about the complicated post. I've changed my setup now. I untared /usr/share/apps/q4os_system/q4home.tar into the /etc/skel directory and added .trinity/share/config/kpersonalizerrc with the content as above ([General]\nFirstLogin=False). I renamed /etc/profile.d/q4os_profile.sh to /etc/profile.d/q4os_profile.sh.norun. Now when creating a new user, the home directory is properly populated and can be used without starting X. Cheers.

Offline

Board footer

Powered by FluxBB