ssh could not chdir to home directory

livewire98801 · 09-30-2008, 03:57 PM

Quote:

Originally Posted by billymayday

If this had been an SELinux issue, it would simply have meant that the contexts for the home directory had gotten messed up, and a simple restorecon would have fixed things up (or at least should).

For your ftp issue, I'll make two points.

The first is that setenforce is not persistent, so at very least you will either need to disable it permanently or re-enter seenforce 0 each time you boot. If you run gnome, there is a security setting program, otherwise the seting will be in /etc/selinux somewhere.

A better solution (if you like screwdriver solutions over sledgehammers) is to either set your own policies (you need to be reasonably keen here), or you can disable SELinux for sertain actions. Not sure of your directory structure, but here's what I have that looks relevant in /selinux/booleans:

Code:

allow_ftpd_anon_write   allow_ftpd_use_cifs  allow_tftp_anon_write  ftpd_is_daemon  httpd_enable_ftp_server
allow_ftpd_full_access  allow_ftpd_use_nfs   ftpd_disable_trans     ftp_home_dir    tftpd_disable_trans

The relative sledgehammer here is to "setsebool -P ftpd_disable_trans 1", but if your issue is just with working with home directories, setting ftp_home_dir may do it for you.

Not sure which ftp daemon you use or if will necessarily work for your situation. I use vsftpd, and here is what's set for me:

Code:

# for i in $(ls /selinux/booleans/*ftp*); do getsebool $i; done
allow_ftpd_anon_write --> off
allow_ftpd_full_access --> off
allow_ftpd_use_cifs --> off
allow_ftpd_use_nfs --> off
allow_tftp_anon_write --> off
ftpd_disable_trans --> off
ftpd_is_daemon --> on
ftp_home_dir --> on
httpd_enable_ftp_server --> on
tftpd_disable_trans --> off

I'm just going to disable (permanently), but thank you for posting this for other users who might want to keep it around

RLIN · 06-04-2009, 01:05 PM

I tried to move /home to different partition and got the following problem when trying to login:

Last login: Thu Jun 4 13:03:08 2009 from *.*.*.*
Could not chdir to home directory /home/[ME]: Permission denied

although permission, SELinux context are exactly the same as the originals.

After this error, system stays at / and lets me in, and no other errors after that. Even su - [ME] does not issue any errors and goes to /home/[ME] directory correctly.

Here are related infos:
lrwxrwxrwx root root system_u

bject_r:home_root_t:s0 home -> /app/home
drwxr-xr-x root root system_u

bject_r:home_root_t:s0 home_hold

drwx------ [ME] [ME] system_u

bject_r:user_home_dir_t:s0 [ME]

Any idea?

livewire98801 · 06-04-2009, 02:30 PM

What distro are you using?

Try

Code:

 sudo setenforce 0

from the commandline and try again, that will confirm or exclude selinux as the source of your problem.

Quote:

Originally Posted by RLIN

I tried to move /home to different partition and got the following problem when trying to login:

Last login: Thu Jun 4 13:03:08 2009 from *.*.*.*
Could not chdir to home directory /home/[ME]: Permission denied

although permission, SELinux context are exactly the same as the originals.

After this error, system stays at / and lets me in, and no other errors after that. Even su - [ME] does not issue any errors and goes to /home/[ME] directory correctly.

Here are related infos:
lrwxrwxrwx root root system_u

bject_r:home_root_t:s0 home -> /app/home
drwxr-xr-x root root system_u

bject_r:home_root_t:s0 home_hold

drwx------ [ME] [ME] system_u

bject_r:user_home_dir_t:s0 [ME]

Any idea?

billymayday · 06-04-2009, 03:58 PM

What distro are you using?

On CentOS, correct context for jome directories is user_u:object_r:user_home_dir_t not system_u:object_r:user_home_dir_t

RLIN · 06-04-2009, 09:26 PM

Distro: Fedora 10

What should be the context of the softlink /home
(It seems that it should not be the same as the original directory's
system_u

bject_r:home_root_t:s0 home )

Here is the Security log:

When squirrel mail tries to loging:
SELinux is preventing dovecot (dovecot_t) "read" to home (home_root_t).

Source Context: system_u:system_r:dovecot_t:s0Target
Context: system_u

bject_r:home_root_t:s0Target
Objects: home [ lnk_file ]

When: ssh tries to login:
SELinux is preventing sshd (sshd_t) "read" to home (home_root_t).

Source Context: system_u:system_r:sshd_t:s0-s0:c0.c1023Target
Context: system_u

bject_r:home_root_t:s0Target
Objects: home [ lnk_file ]

Quote:

Originally Posted by billymayday

What distro are you using?

On CentOS, correct context for jome directories is user_u

bject_r:user_home_dir_t not system_u

bject_r:user_home_dir_t

RLIN · 06-04-2009, 10:06 PM

Quote:

Originally Posted by livewire98801

What distro are you using?

Try

Code:

 sudo setenforce 0

from the commandline and try again, that will confirm or exclude selinux as the source of your problem.

Thank you very much, livewire98801,

I had to correct audit violations by the followings:

audit2allow -M spamd -i /var/log/audit/audit.log
semodule -i spamd.pp

I can have a good sleep now,

RLIN · 06-04-2009, 10:11 PM

Quote:

Originally Posted by RLIN

Thank you very much, livewire98801,

I had to correct audit violations by the followings:

audit2allow -M spamd -i /var/log/audit/audit.log
semodule -i spamd.pp

I can have a good sleep now,

Can anyone tell me why I did not have this problem before
moving /home to different partition?

It seems softlink plays a major role here because I compare /home (softlink), /app/home (new home) and /home_hold (original home).
They have exactly the same owner, mod, contect.

billymayday · 06-04-2009, 10:28 PM

Where doe the link link to and what is the context of the target? I still expect the context needs to be user_u

RLIN · 06-05-2009, 12:03 PM

Quote:

Originally Posted by billymayday

Where doe the link link to and what is the context of the target? I still expect the context needs to be user_u

Checked the other system (Fedora 7), found the same context system_u of /home, however, I changed /home and its target /app/home on this system (Fedora 10) to user_u, and it still works also. I think "touch /.autorelabel;reboot" changed lots of context to system_u

bject_r:default_t, and I had to compare with (Fedora 7) to change them back.

In such case, I am going to move /var/log and /www out, should I changed /www to user_u also and keep system_u for /var/log?

Thanks,

RLIN · 06-05-2009, 01:51 PM

Quote:

Originally Posted by RLIN

Checked the other system (Fedora 7), found the same context system_u of /home, however, I changed /home and its target /app/home on this system (Fedora 10) to user_u, and it still works also. I think "touch /.autorelabel;reboot" changed lots of context to system_u

bject_r:default_t, and I had to compare with (Fedora 7) to change them back.

In such case, I am going to move /var/log and /www out, should I changed /www to user_u also and keep system_u for /var/log?

Thanks,

And,
I had not problem to move /www because I can check audit log and correct them.
However, I had problem to move /var/log because nothing will be logged in audit.

Any idea to corret this problem?

Thanks,

billymayday · 06-05-2009, 04:11 PM

/var/log is var_log_t, whereas /var is var_t

RLIN · 06-05-2009, 05:43 PM

Quote:

Originally Posted by billymayday

/var/log is var_log_t, whereas /var is var_t

Yes, they are set this way,
I think the only way available to me now is to
have /var/log in a LogVol itself and mount them during boot time. Later, I can move /www, /home here because
errors will be logged and fixed accordingly.

The softlink /var/log -> /app/log did not work, and errors were not logged. I had no way to fix it.

Thanks, billymayday,

kwiji · 08-24-2012, 10:30 AM

I realize this is an old thread but as it is still the first hit I found on Google, I'll post my solution in case it helps someone.

I was having this same issue on Red Hat 6. This machine has a combination of local and Active Directory users using Samba/Winbind for authentication. This involved a local user who ran into this issue that we'll call 'user1'. He made the mistake of attempting a login with his caps lock on effectively logging in as 'USER1'. This failed but when he attempted to login again he got the permission error. We have our Samba/Winbind set to auto-create a directory for new users if it doesn't exist. I suspect that there is some sort of case-insensitive bug or something that tried to touch the existing /home/user1 directory.

To fix I simply reset the regular perms and it worked
1) login as root
2) cd /home
3) chown user1:user1 user1
4) chmod 700 user1

I hope this helps.