tde-devels November 2013

devels@trinitydesktop.org

8 participants
30 discussions

Re: [trinity-devel] Solution for hardcoded sudo in konsole schemas

by Darrell Anderson

>to resolve bug report 853 is ready a patch that selects between >"sudo su" >and "su" depending on the build option WITH_SUDO_TDESU_BACKEND. > >But as we have noticed, also on Ubuntu is used >WITH_SUDO_TDESU_BACKEND=OFF. >This would mean that even Ubuntu would not be used "sudo". > >That's why I asked what solution to choose for Ubuntu packaging? > >1) Apply the patch and leave WITH_SUDO_TDESU_BACKEND=OFF >2) Apply the patch, but change WITH_SUDO_TDESU_BACKEND=ON >3) Make a separate build option WITH_SUDO_KONSOLE_BACKEND > >See: http://bugs.pearsoncomputing.net/show_bug.cgi?id=853 I'm not an Ubuntu user but I'm fine with adding WITH_SUDO_KONSOLE_BACKEND as a new option. Would the default be WITH_SUDO_KONSOLE_BACKEND=OFF, meaning sudo- based disto packagers would have to explicitly change that option to WITH_SUDO_KONSOLE_BACKEND=ON? Darrell

11 years, 4 months

Solution for hardcoded sudo in konsole schemas

by Slávek Banko

Hi all, to resolve bug report 853 is ready a patch that selects between "sudo su" and "su" depending on the build option WITH_SUDO_TDESU_BACKEND. But as we have noticed, also on Ubuntu is used WITH_SUDO_TDESU_BACKEND=OFF. This would mean that even Ubuntu would not be used "sudo". That's why I asked what solution to choose for Ubuntu packaging? 1) Apply the patch and leave WITH_SUDO_TDESU_BACKEND=OFF 2) Apply the patch, but change WITH_SUDO_TDESU_BACKEND=ON 3) Make a separate build option WITH_SUDO_KONSOLE_BACKEND See: http://bugs.pearsoncomputing.net/show_bug.cgi?id=853 Thank you Slavek

11 years, 4 months

RE: [trinity-devel] Possible security glitch with switching users?

by Darrell Anderson

>Agreed, the behavior should be as you described and should be >consistent all the times. >Since you can reproduce the problem several times, I think there >is enough material to open a new bug report. Tim implied the witnessed behavior is correct. One of you gurus would have to walk through the code to determine whether locking is expected when not explicitly selected from the menu. Darrell

11 years, 4 months

Re: [trinity-devel] Possible security glitch with switching users?

by Darrell Anderson

>Darrell, how long did you work in one session before switching to >the other one? Just wondering if there is some kind of inactivity >timer that locks a session when not being used for a while. That >may explain the different behavior you have seen, even though it >sounds a little weird to say the least Not long, about 5 seconds. Another person suggested there might be a timeout of some sort regulating when the lock dialog appears. Yet I'm confused. Seems to me there should be no password required when using 'Start New Session' --- that is what the 'Lock Current & Start New Session' option should be for. Darrell

11 years, 4 months

Re: [trinity-devel] Possible security glitch with switching users?

by Darrell Anderson

>AFAIK "Start New Session" does not lock the current session, >whereas >selecting an existing session will lock the current session. On my >systems >there is a second menu entry for "Lock Current & Start New >Session" if it >is desired to lock the screen before starting the new session. That is confusing behavior to me. I'll guess confusing to others too. Darrell

11 years, 4 months

Re: [trinity-devel] Possible security glitch with switching users?

by Darrell Anderson

>I don't know whether this is a security glitch or PEBKAC. > >I was testing the graphical login with TDM: > >* I logged in as User 1. >* From the TDE menu I selected Switch User->Start New Session. >* I logged in as User 2. >* I switched to User 1 *without* needing a password. >* I switched to User 2 and needed a password. >* I typed the password, switched to User 1, and needed a password. > >I repeated this exercise three times with a system reboot each >time. Each time the first instance of switching did not require a >password. > >Further, I was not always asked for a password on subsequent >switching, especially when I used the keyboard toggles of Ctrl-Alt- > >F7 and Ctrl-Alt-F8. > >SAK is disabled. > >I only used Switch User->Start New Session. I did not use Switch >User->Lock Current & Start New Session. > >Thoughts? BTW, seems to me there should be no password required when using 'Start New Session' --- that is what the 'Lock Current & Start New Session' option should be for? Darrell

11 years, 4 months

Possible security glitch with switching users?

by Darrell Anderson

All, I don't know whether this is a security glitch or PEBKAC. I was testing the graphical login with TDM: * I logged in as User 1. * From the TDE menu I selected Switch User->Start New Session. * I logged in as User 2. * I switched to User 1 *without* needing a password. * I switched to User 2 and needed a password. * I typed the password, switched to User 1, and needed a password. I repeated this exercise three times with a system reboot each time. Each time the first instance of switching did not require a password. Further, I was not always asked for a password on subsequent switching, especially when I used the keyboard toggles of Ctrl-Alt- F7 and Ctrl-Alt-F8. SAK is disabled. I only used Switch User->Start New Session. I did not use Switch User->Lock Current & Start New Session. Thoughts? Darrell

11 years, 4 months

Re: [trinity-devel] Possible remnant XDG x-kde instances

by Darrell Anderson

>> Should these instances be converted to x-tde-*? > >I would think so. I will push the changes. Darrell

11 years, 4 months

Possible remnant XDG x-kde instances

by Darrell Anderson

All, After resolving bug report 1704 I searched the Trinity source tree for additional occurrences of 'kde-'. I found several instances of some XDG mimetype references that have not been converted to TDE nomenclature. The list: x-kde-internaluid x-kde-type x-kde-cutselection x-kde-urilist A short list, yet I'm curious whether any of these instances could be causing or are related to reported problems in Trinity. To see these instances in context, grep tdebase, tdelibs, tdepim, krusader, basket. Should these instances be converted to x-tde-*? Darrell

11 years, 4 months

commit 99b03be6 (qt3/tqt3)

by Slávek Banko

Hi all, after commit 99b03be6 I have on a test machine in .xsession-errors many such reports. Note that it is the testing machine, on which is now the only active screen saver. TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x1508ad0 TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x150b400 TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x150afb0 TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x1508af0 TQThreadInstance::finish: In TQThreadInstance::finish for thread 0x150b420 To this I have two questions: 1) How can such a report be useful when there is no knowing what applications are affected? 2) Tim, why you use in such reports, a new lines with "\r"? Thanks Slavek

11 years, 4 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels November 2013