Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
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
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_ubject_r:home_root_t:s0 home -> /app/home
drwxr-xr-x root root system_ubject_r:home_root_t:s0 home_hold
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_ubject_r:home_root_t:s0 home -> /app/home
drwxr-xr-x root root system_ubject_r:home_root_t:s0 home_hold
What should be the context of the softlink /home
(It seems that it should not be the same as the original directory's
system_ubject_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_ubject_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_ubject_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_ubject_r:user_home_dir_t not system_ubject_r:user_home_dir_t
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.
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_ubject_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?
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_ubject_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.
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.
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.