Hi,
I created a new user using kuser. I wanted to change his password with passwd user : $ su $ passwd user
I got the following error: passwd: Erreur de manipulation du jeton d'authentification
Then I did: $ setenforce 0 and it worked.
Later, I reenabled selinux: $ setenfoce 1
and the user tried to login with sddm to Plasma -> got a black screen then back to sddm.
removed selinux: $ setenforce 0
Login to Plasma worked
What's wrong with SELinux?
Frédéric
On 18 September 2017 at 14:24, Frédéric Bron frederic.bron@m4x.org wrote:
Hi,
I created a new user using kuser. I wanted to change his password with passwd user : $ su $ passwd user
I got the following error: passwd: Erreur de manipulation du jeton d'authentification
Then I did: $ setenforce 0 and it worked.
Later, I reenabled selinux: $ setenfoce 1
and the user tried to login with sddm to Plasma -> got a black screen then back to sddm.
removed selinux: $ setenforce 0
Login to Plasma worked
What's wrong with SELinux?
Frédéric _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
What is the label for /etc/passwd and /etc/shadow, this may be unrelated but I have experienced a similar issue and the /etc/shadow was not labelled correctly by SELinux.
What is the label for /etc/passwd and /etc/shadow, this may be unrelated but I have experienced a similar issue and the /etc/shadow was not labelled correctly by SELinux.
after relabeling I have: # ls -Z /etc/{passwd,shadow} unconfined_u:object_r:passwd_file_t:s0 /etc/passwd unconfined_u:object_r:shadow_t:s0 /etc/shadow
This is strange because on another F26 computer, I have that: system_u:object_r:passwd_file_t:s0 /etc/passwd system_u:object_r:shadow_t:s0 /etc/shadow
Frédéric
On 09/20/17 14:14, Frédéric Bron wrote:
What is the label for /etc/passwd and /etc/shadow, this may be unrelated but I have experienced a similar issue and the /etc/shadow was not labelled correctly by SELinux.
after relabeling I have: # ls -Z /etc/{passwd,shadow} unconfined_u:object_r:passwd_file_t:s0 /etc/passwd unconfined_u:object_r:shadow_t:s0 /etc/shadow
This is strange because on another F26 computer, I have that: system_u:object_r:passwd_file_t:s0 /etc/passwd system_u:object_r:shadow_t:s0 /etc/shadow
I just performed an "autorelabel" on an F26 VM and did not have this experience. Those files remained properly labeled.
A few questions....
1. Is the file /.autorelabel gone? It should be, after a relabel.
2. Do you happen to know what the labels were previously?
3. If you do a "restorecon /etc/passwd" is the label then correct?
A few questions....
- Is the file /.autorelabel gone? It should be, after a relabel.
yes and I saw the relabeling operation. After that, the computer rebooted.
- Do you happen to know what the labels were previously?
Halas, I do not know.
- If you do a "restorecon /etc/passwd" is the label then correct?
I guess no: unconfined_u:object_r:passwd_file_t:s0 passwd unconfined_u:object_r:shadow_t:s0 shadow
Frédéric
On 09/20/17 16:22, Frédéric Bron wrote:
A few questions....
- Is the file /.autorelabel gone? It should be, after a relabel.
yes and I saw the relabeling operation. After that, the computer rebooted.
- Do you happen to know what the labels were previously?
Halas, I do not know.
- If you do a "restorecon /etc/passwd" is the label then correct?
I guess no: unconfined_u:object_r:passwd_file_t:s0 passwd unconfined_u:object_r:shadow_t:s0 shadow
I see...
What do you get for
ls -Zd /etc
?
On 09/20/17 17:33, Frédéric Bron wrote:
ls -Zd /etc
system_u:object_r:etc_t:s0 /etc/
looks fine?
Yes, perfectly fine...
How the output of this?
restorecon -F -v /etc/passwd
FWIW, looking in /etc/selinux/targeted/contexts/files/file_contexts I see....
/etc/passwd[-+]? -- system_u:object_r:passwd_file_t:s0
But, at the moment I don't know the significance of [-+]? at the end.
On 09/20/17 18:13, Frédéric Bron wrote:
How the output of this?
restorecon -F -v /etc/passwd
Relabeled /etc/passwd from unconfined_u:object_r:passwd_file_t:s0 to system_u:object_r:passwd_file_t:s0
So the force option was necessary?
Yes.... But I don't think unconfined_u:object_r:passwd_file_t:s0 would have caused any issues.
I did the following test....
[root@f26-rc15k etc]# ls -Z passwd system_u:object_r:passwd_file_t:s0 passwd [root@f26-rc15k etc]# mv passwd passwd.orig [root@f26-rc15k etc]# cp passwd.orig passwd [root@f26-rc15k etc]# ls -Z passwd unconfined_u:object_r:passwd_file_t:s0 passwd [root@f26-rc15k etc]# matchpathcon -V passwd passwd verified. [root@f26-rc15k etc]# restorecon -F -v passwd Relabeled /etc/passwd from unconfined_u:object_r:passwd_file_t:s0 to system_u:object_r:passwd_file_t:s0 [root@f26-rc15k etc]# matchpathcon -V passwd passwd verified.
So, you can see that in both cases matchpathcon verified the context.
On Wed, Sep 20, 2017 at 05:54:19PM +0800, Ed Greshko wrote:
On 09/20/17 17:33, Frédéric Bron wrote:
ls -Zd /etc
system_u:object_r:etc_t:s0 /etc/
looks fine?
Yes, perfectly fine...
How the output of this?
restorecon -F -v /etc/passwd
FWIW, looking in /etc/selinux/targeted/contexts/files/file_contexts I see....
/etc/passwd[-+]? -- system_u:object_r:passwd_file_t:s0
But, at the moment I don't know the significance of [-+]? at the end.
I suspect it is an extended RE. The "[-+]" would be a character class that includes "-", "", and "+". the "?" makes it optional. I.e. the name "/etc/passwd" matches with one of the three characters after the "d" or without any character after the "d".
jl
On 09/18/2017 11:24 AM, Frédéric Bron wrote:
Hi,
I created a new user using kuser. I wanted to change his password with passwd user : $ su $ passwd user
I got the following error: passwd: Erreur de manipulation du jeton d'authentification
Then I did: $ setenforce 0 and it worked.
Later, I reenabled selinux: $ setenfoce 1
and the user tried to login with sddm to Plasma -> got a black screen then back to sddm.
removed selinux: $ setenforce 0
Login to Plasma worked
What's wrong with SELinux?
I mistakenly replied directly to Frederic, not the list. Whoops! Anyway, this is what I said so there's a record:
"Probably nothing. You need to relabel your files as you've likely done things with SELinux disabled. If so, the things that were done with it disabled have the wrong SELinux contexts.
"As the root user, "touch /.autorelabel", then enable SELinux and reboot. The reboot will take a while as the system walks all the filesystems and relabels files and directories with the correct contexts.
"Don't just enable and disable SELinux willy-nilly. If you have it enabled and something doesn't work, use the AVC mechanisms to find out WHY it didn't work. It may be an SELinux policy that's wrong or it may be that some processes/programs are not adhering to SELinux properly (for example, ZoneMinder has LOTS of SELinux violations)."
---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - The world is coming to an end ... SAVE YOUR FILES!!! - ----------------------------------------------------------------------
On 09/19/2017 07:14 PM, Rick Stevens wrote:
On 09/18/2017 11:24 AM, Frédéric Bron wrote:
Hi,
I created a new user using kuser. I wanted to change his password with passwd user : $ su $ passwd user
I got the following error: passwd: Erreur de manipulation du jeton d'authentification
Then I did: $ setenforce 0 and it worked.
Later, I reenabled selinux: $ setenfoce 1
and the user tried to login with sddm to Plasma -> got a black screen then back to sddm.
removed selinux: $ setenforce 0
Login to Plasma worked
What's wrong with SELinux?
I mistakenly replied directly to Frederic, not the list. Whoops! Anyway, this is what I said so there's a record:
"Probably nothing. You need to relabel your files as you've likely done things with SELinux disabled. If so, the things that were done with it disabled have the wrong SELinux contexts.
"As the root user, "touch /.autorelabel", then enable SELinux and reboot. The reboot will take a while as the system walks all the filesystems and relabels files and directories with the correct contexts.
"Don't just enable and disable SELinux willy-nilly. If you have it enabled and something doesn't work, use the AVC mechanisms to find out WHY it didn't work. It may be an SELinux policy that's wrong or it may be that some processes/programs are not adhering to SELinux properly (for example, ZoneMinder has LOTS of SELinux violations)."
Correct, when you disabling SELinux, always use autorelabel, it can save you lot of time troubleshooting what's wrong.
Next thing, If you have some SELinux issue, like this when in Enforcing mode is some thing broken and when you put it in Permissive (# setenforce 0), you can check audit logs if there is any SELinux denials. For example: (# ausearch -m AVC,USER_AVC -ts today).
These messages will tell you why was some action denied by SELinux.
Thanks, Lukas.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
-
The world is coming to an end ... SAVE YOUR FILES!!! -
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org