| Summary: | Logging to TDE takes more than 10 seconds. | ||
|---|---|---|---|
| Product: | TDE | Reporter: | f_ii <f_ii> |
| Component: | tdebase | Assignee: | Francois Andriot <albator78> |
| Status: | RESOLVED NOTOURPROBLEM | ||
| Severity: | major | CC: | albator78, bugwatch, darrella, f_ii, michele.calgaro |
| Priority: | P5 | ||
| Version: | 3.5.13 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
f_ii
2012-11-28 11:00:43 CST
Login is immediate here with Slackware using the login manager. As you are using Fedora, Francois should get involved. Hello, sorry I do not have a Fedora 17 physical machine. But I've just installed a Fedora17 x86_64 in virtual machine (vmware) with default KDE4 installation, then installed TDE on top of it, and I do not have the "long login time" you describe. Only the first login (when the kpersonalizer is launched) is a bit longer than usual, but every next login is fast as expected. Can you be more specific with your current setup ? - Do you have KDE4/Gnome/any other desktop installed beside TDE ? - Which DM do you use ? KDM, TDM, GDM, other ? - How did you install your computer ? From the TDE LiveCD, or from the standard Fedora DVD ? The "long login time" problem reminds me of a more general Linux configuration problem, when the system cannot resolve it's own hostname. E.g: ping $HOSTNAME => unknown host (In reply to comment #2) > Hello, sorry I do not have a Fedora 17 physical machine. > But I've just installed a Fedora17 x86_64 in virtual machine (vmware) with > default KDE4 installation, then installed TDE on top of it, and I do not have > the "long login time" you describe. > Only the first login (when the kpersonalizer is launched) is a bit longer than > usual, but every next login is fast as expected. > > Can you be more specific with your current setup ? > - Do you have KDE4/Gnome/any other desktop installed beside TDE ? Neither KDE4 nor GNOME installed, just base to be able to run their apps in TDE. See attached list of installed packages. > - Which DM do you use ? KDM, TDM, GDM, other ? I just use TDM, neither kdm not gdm are installed. > - How did you install your computer ? From the TDE LiveCD, or from the standard > Fedora DVD ? I've installed F17+TDE from spin iso downloaded from TDE website: e3366ad8a8ef666a162651c67bcfffc0 TDE_FC17_x86_64.iso Then I updated system via yum... > > The "long login time" problem reminds me of a more general Linux configuration > problem, when the system cannot resolve it's own hostname. > E.g: > ping $HOSTNAME > => unknown host Not my case. ping and networking works well. OK I've reproduced the bug on Fedora 17 x86_64 virtual machine. Some analysis (alas no solution) below. VM is configured to use TDM as display manager. I press CTRL+ALT+DEL then enter login, password, enter... THen, for an unknown reason, TDM waits about 10 seconds before running "startkde" script. Even if I choose another desktop (e.g Gnome), I have the same latency, so it is really related to TDM. Now some weird tests: - Switch to runlevel 3 so that graphical interface is stopped (back to console mode) - Log in as root, run /opt/trinity/bin/kdm in terminal. => TDM starts, works correclty, no latency. - Kill TDM, run "/etc/X11/prefdm" in terminal (this Fedora's shell script chooses between GDM, XDM, KDM, etc ... Basically it ends up doing 'exec /opt/trinity/bin/kdm'). => TDM starts, latency is back ! - Kill TDM. Now run previous script with "sh /etc/X11/prefdm" => TDM starts, no latency ! It is 100% reproducible here. So, there is an non-obvious difference between running "/etc/X11/prefdm" and "sh /etc/X11/prefdm". I think there is some sort of Fedora security related setting that messes up with TDM. It is definitely a security setting issue, but finally it looks like it is not a PAM problem.
Disabling selinux works around the problem.
The following message is issued in '/var/log/audit/audit.log' when opening a session in TDM:
type=USER_AVC msg=audit(1355052696.923:148): pid=508 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=error error_name=net.reactivated.Fprint.Error.NoSuchDevice dest=:1.131 spid=3693 tpid=3672 scontext=system_u:system_r:fprintd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
Then it pauses a few seconds, then the PAM log messages comes up and the session opens correctly.
I'm not an expert with selinux, but apparently you can define new rules directly from the log file.
Try the following command (as root, it is a single command on a single line):
echo "type=USER_AVC msg=audit(1355053725.441:101): pid=567 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=error error_name=net.reactivated.Fprint.Error.NoSuchDevice dest=:1.80 spid=2618 tpid=2581 scontext=system_u:system_r:fprintd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'" | audit2allow -M tdm
Then (this one takes a few seconds):
semodule -i tdm.pp
It looks like it solves the problem.
Alas, I have no idead if this a good practice or not.
Is this a Trinity problem or Fedora? If the latter then should this report be closed? I'm going to retest shortly. It looks like it is underlying Fedora problem, see below bug for more details... https://bugzilla.redhat.com/show_bug.cgi?id=795506 Darraell, I do not reproduce the bug on other distro, so this is Fedora-specific. f_ii, thanks for pointing that bug. I see there are several references to "kde3" in Fedora's Selinux configuration files, so I will try to imitate this for Trinity and see if it works. Do not close the bug yet. Just tried Fedora 18 x86_64 fresh install, TDE 3.5.13.2~pre : this problem does not occur anymore. About one month ago, problem existed in Fedora 18. But this distro receives so much updates so quickly, I cannot tell which package update solved this. I will now try in Fedora 17 (still supported), then on Centos 6 (I've seen this bug appearing on Centos 6 recently !!!) Bug is still present in current Centos 6 and current Fedora 17. I do not manage to configure a proper Selinux file context for TDE that works in Fedora/Centos, so I just push the (bad) workaround given above in my Centos6/Fedora17 packages. It will be there in 3.5.13.2 final and later. I am closing this bug since as explained at comment 8 and comment 10, it seems to be a distro (Fedora/CentOS) specific problem. Feel free to reopen it if it proves to be a TDE related bug. |