When I upgraded my fedora boxes in a cluster to fedora 13, I found that I can nolonger login locally via graphical interface, and remote login dropped me to / since it could not change dir to user home.
I then
setenforce 0
All back to normal.
However,
audit2allow -m local -l -i /var/log/audit/audit.log
did not show any error, so do
grep seal /var/log/messages
And I did not find any reasonable solution from internet.
For order version of fedora, I used to use local.te to enable /home through nfs. Now in version 13 it can be done by
setsebool -P use_nfs_home_dirs=1
But this did not change anything here.
So I went to check the path of real /home, and found that “home” has nfs_t attibute since it is a nfs mount. This is supposed to be resolved by the above means. However, “home” is not mounted under /, but under /data, which is attributed default_t. I believe that this is the cause of the failure.
To solve this, I made a local.te file as
module local 1.0;
require {
type local_login_t;
type default_t;
type xauth_t;
type sshd_t;
class dir search;
}
#============= sshd_t ==============
allow sshd_t default_t:dir search;
#============= xauth_t ==============
allow xauth_t default_t:dir search;
#============= local_login_t ==============
allow local_login_t default_t:dir search;
This allows sshd, xauth and local_login to go through default_t.
By inserting this to the selinux policy, the issue is fixed.
13 Comments
Leave a Reply
You must be logged in to post a comment.
This is really interesting, You’re a very skilled blogger. I have joined your feed and look forward to seeking more of your great post. Also, I’ve shared your site in my social networks!
But nevertheless, naturally arena of which this hours extended in between areas, a significant promote (31% of this finish in 2004, in line with the BIS) to be able to undertaking will be mentally within United kingdom.
We are a team of volunteers and starting a new plan in our group. Your web page provided us with beneficial info to work on. You’ve done an impressive work and our entire group will likely be grateful to you.
very interesting points you have noted , thankyou for putting up.
I think this internet site holds very wonderful pent content material posts .
I gotta bookmark this internet site it seems very useful handy
Well said. I was able to use the information here. I’ll bookmark this site for future upadtes. Thanks again.
I was been trying to find the WWW for this info and i wanted to say thanks to you for this post. Also, just off topic, how can i get a version of this theme? – Thank you
I was been after the WWW for this info and i wanted to say thanks to you for this post. BTW, just off topic, where can i download a copy of this theme? – Regards
you are my inspiration , I possess few web logs and infrequently run out from to post : (.
Browsing the web, I ran across your webblog. I am hunting for various ideas for a theme for my own site. I like the design, did you make or alter this layout? I have a site also and my layout is kinda bad as a result people don’t stay on my blog very long.
Genial brief and this enter helped me alot in my college assignement. Thank you as your information.
The above workaround is flawed. It still did not allow login through
authorized_keys. To make this possible, the local policy should be:
_________________________________________________________________
module local 1.0;
require {
type local_login_t;
type default_t;
type xauth_t;
type sshd_t;
class dir { search getattr };
}
#============= sshd_t ==============
allow sshd_t default_t:dir { search getattr };
#============= xauth_t ==============
allow xauth_t default_t:dir search;
#============= local_login_t ==============
allow local_login_t default_t:dir search;
__________________________________________________________________
To be noted, the reason I report this self-solved issue as a bug is because of
its inconsistencies:
a) It did not generate any denial log in /var/log/audit/audit.log, which made
the debugging unnecessarily difficult;
b) Although it prevented the login process to change dir to user root, and drop
user log in point to /, after logged on, user can “cd ~” without any problem.
This means that the selinux policies for login process is inconsistent with
user shell, like bash or tcsh;
c) This issue did not exist in Fedora 12, means that it was created in the
development of Fedora 13;
d) Up to date, Fedora overnight update did not fix this issue.