Jump to content

Strange su/login problem


scoonma
 Share

Recommended Posts

Hi all,

 

I recently stumbled over a strange problem of similar type Urza reported of:

 

Unable to login as *any* user, I still can login to the system (Mandriva 2007 cooker) as root. Trying to login as normal user from console (i.e. "login: " prompt, the system kicks me out immediately. By lowering processor speed I was able to see the small error message: It says there is no home directory for that user, but it actually exists! There is no kernel message giving any hint on "F-12 console", no valuable information on /var/log/messages or /var/log/secure.

 

When trying to "su <user>" after root login, the only error is "could not open session". By googling I found out that this could be caused by file permissions wrongly set. So I've checked the following (which should be okay, AFAIK):

 

/etc drwxr-xr-x

/etc/pam.d drwxr-xr-x

/etc/passwd rw-r--r--

/etc/shadow rw-------

 

It does not matter wether trying to use an existing user in /home or after creating a new one with "useradd", so it's likely to be a system wide error. Last option that came to my mind is to use strace. I tried

 

"strace -oout.txt su <user>" and found the following:

 

[...]

open("/etc/pam.d/other", O_RDONLY|O_LARGEFILE) = 3

fstat64(3, {st_mode=S_IFREG|0644, st_size=154, ...}) = 0

mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000

read(3, "#%PAM-1.0\nauth required "..., 131072) = 154

read(3, "", 131072) = 0

close(3) = 0

munmap(0xb7d01000, 131072) = 0

getuid32() = 0

getuid32() = 0

open("/etc/passwd", O_RDONLY) = 3

fcntl64(3, F_GETFD) = 0

fcntl64(3, F_SETFD, FD_CLOEXEC) = 0

fstat64(3, {st_mode=S_IFREG|0644, st_size=1340, ...}) = 0

mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000

read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 131072) = 1340

close(3) = 0

munmap(0xb7d01000, 131072) = 0

time(NULL) = 1155194279

getuid32() = 0

getuid32() = 0

open("/etc/passwd", O_RDONLY) = 3

fcntl64(3, F_GETFD) = 0

fcntl64(3, F_SETFD, FD_CLOEXEC) = 0

fstat64(3, {st_mode=S_IFREG|0644, st_size=1340, ...}) = 0

mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000

read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 131072) = 1340

close(3) = 0

munmap(0xb7d01000, 131072) = 0

open("/etc/shadow", O_RDONLY) = 3

fcntl64(3, F_GETFD) = 0

fcntl64(3, F_SETFD, FD_CLOEXEC) = 0

fstat64(3, {st_mode=S_IFREG|0600, st_size=831, ...}) = 0

mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000

read(3, "root:$1$pAlg6jqo$Q4EOt4pn2aApAsq"..., 131072) = 831

close(3) = 0

munmap(0xb7d01000, 131072) = 0

time(NULL) = 1155194279

setfsuid32(501) = 0

setfsgid32(501) = 0

access("/usr/bin/xauth", X_OK) = 0

open("/etc/passwd", O_RDONLY) = -1 EACCES (Permission denied)

open("/etc/ld.so.cache", O_RDONLY) = -1 EACCES (Permission denied)

open("/lib/tls/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

open("/lib/tls/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

open("/lib/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

open("/lib/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

open("/usr/lib/tls/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

open("/usr/lib/tls/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

open("/usr/lib/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

open("/usr/lib/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied)

getuid32() = 0

ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0

readlink("/proc/self/fd/0", 0x8055f70, 4095) = -1 EACCES (Permission denied)

fstat64(0, {st_mode=S_IFCHR|0600, st_size=makedev(0, 0), ...}) = 0

stat64("/dev/pts", 0xbff16878) = -1 EACCES (Permission denied)

open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 EACCES (Permission denied)

getuid32() = 0

time(NULL) = 1155194279

open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)

open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)

open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)

open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)

socket(PF_FILE, SOCK_DGRAM, 0) = 3

fcntl64(3, F_SETFD, FD_CLOEXEC) = 0

connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 EACCES (Permission denied)

close(3) = 0

write(2, "could not open session\n", 23) = 23

exit_group(1) = ?

 

 

Any ideas please?

 

Greetings,

 

scoonma

 

 

[moved from Software by spinynorman]

Link to comment
Share on other sites

Check the permissions on the home directory. Does it exist? Also, check /etc/passwd by doing this:

 

[ian@europa ~]$ cat /etc/passwd | grep ian
ian:x:500:500:Ian Walker:/home/ian:/bin/bash

 

as I have here filtering by my user. You can see my home directory is /home/ian. So if this isn't pointing to where it should be, do this:

 

usermod -d /home/ian ian

 

if that doesn't work, we need to see if the permissions are screwed:

 

[ian@europa home]$ ls -l | grep ian
drwxr-xr-x  56 ian ian 2544 Aug 10 13:06 ian/

 

so, as you can see, mine is set correct, but maybe your home has other details. Reset it with:

 

chown -R ian:ian /home/ian

 

and that should reset all the files in /home/ian and make sure you're back up and running.

Link to comment
Share on other sites

Hi Ian,

 

thx for your fast response! I've done/re-checked what you suggested (/home dir exists, has correct permissions, ...), but unfortunately it does not help.

 

The clue must be located elsewhere. When being root, "su clamav" or "su adm" (or any other user) do result in the very same error: "could not open session". This is why I'm so puzzled.

 

Regards,

 

scoonma

Link to comment
Share on other sites

I have seen similar error messages after I got a bit too thorough deleting files from my home dir ( I wanted to go back to the default setting, so had deleted most .dirs)

 

did you try creating a fresh user?

Edited by ffi
Link to comment
Share on other sites

Ah, ffi made me think of something. You might need to look to see if your .bash files exist in your /home/username directory. If not, you can always copy them over again from /etc/skel directory.

Link to comment
Share on other sites

Thx for your hints!

 

However, the error resists. Shell is /bin/bash, (as normal). The .bash* files within /home/user dir are all intact (and are rarely touched).

 

When creating new users, their accounts suffer from the same problem (i.e. su/login not possible). The corresponding directories are created though, also the defaults from /etc/skel are copied.

 

I did some further googling and found this page: http://www.wlug.org.nz/EACCES. It states that the EACCES error mentioned above is likely being caused by file permission conflicts, but I don't know which places I still haven't checked. Last "candidate" was /bin/bash; I changed permissions from rwx------ to rwxr-xr-x, but this didn't help either.

 

The offending place must be rather central, but not influencing the root acount in this regard. Hm.

Edited by scoonma
Link to comment
Share on other sites

I use that tool in gentoo, really cool way of doing it. My method I learnt in Mandrake/Mandriva:

 

updatedb && slocate rpmnew

 

and you'll get a load of .conf.rpmnew files listed, and you can then replace them where necessary.

Link to comment
Share on other sites

I've used etc-update but this was doing no good. After rebooting, the whole filesystem was crashed beyond repair. There must have gone something deeply wrong. Now I've reinstalled from scratch (everything except /home) and the system runs fine again. But I hate this sort-of windumb method for fixing...

 

Thx nonetheless!

 

scoonma

Link to comment
Share on other sites

Probably a file ownership prob in the .kde or tmp dir. You could su to a user...

what aioshin said should have fixed it but it might have given an error message you missed?

 

Also a full /home will do this as will a corrupt file in the .kde

 

The best thing as someone already said is create a new user.

Apart from anything else having a spare test user is not a bad idea for playing with themes and such anyway.

Link to comment
Share on other sites

I've used etc-update but this was doing no good. After rebooting, the whole filesystem was crashed beyond repair. There must have gone something deeply wrong. Now I've reinstalled from scratch (everything except /home) and the system runs fine again. But I hate this sort-of windumb method for fixing...

 

Thx nonetheless!

 

scoonma

Sorry :sad:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...