| Summary: | .config and ,bash_history created in / | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | james Whitby <jim> |
| Component: | Security | Assignee: | John Balcaen <balcaen.john> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | balcaen.john, davidwhodgins, stormi-mageia |
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=249217 | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
|
Description
james Whitby
2011-06-19 16:41:10 CEST
Please ignore the reference to .bash_history. That is/was a different problem. The .bash_history in the root directory gets created anytime you start in run level 1. The .config directory did exist in my Mageia 1 clean install, however, once I delete it, it does not get recreated on my system. Same with my Mageia Cauldron installation. CC:
(none) =>
davidwhodgins so, do we know where this .config comes from ? I have it on my system too but never SSHed to the machine. CC:
(none) =>
stormi
Samuel Verschelde
2011-10-01 13:33:52 CEST
Keywords:
(none) =>
NEEDINFO I ran quite a few tests, each time starting with a minimal+lxde install, using run level 3. Installing task-kde4-minimal from a lxde-terminal /.config/trolltech.conf was created (based on the timestamp and /var/log/syslog entries) during the processing of the file-triggers from kdebase4-workspace. The dbus configuration was reloaded 4 times as kdebase4-workspace was installed. Based on the time and ps output, the file was created the same second a kwin task was started (only process started that second still running when I checked the ps output). But, during 6 repeat installs under various conditions, including one just like the above, it was never recreated. System was restored from image each time I repeated the test, so I no longer have anything from the one time it was created. I'm using a single core processor, so this makes a race condition less likely. Hopefully this will help narrow down the cause, and not cause a wild goose chase. :-) And I didn't even think of looking *inside* the .config directory! It's a Trolltech.conf file too. Assigning to mikala in case he knows about this. Assignee:
bugsquad =>
balcaen.john
Samuel Verschelde
2011-10-02 09:03:16 CEST
Keywords:
NEEDINFO =>
(none) Well i guess if there's a file trigger launching/updating a Qt related app it's normal to have the config file from Qt created since urpmi works as root. But from what i'm reading it's not related to the startx problem at all. Maybe we should check which argument are passed to ssh before starting the xserver ? CC:
(none) =>
balcaen.john (In reply to comment #6) > Well i guess if there's a file trigger launching/updating a Qt related app it's > normal to have the config file from Qt created since urpmi works as root. > But from what i'm reading it's not related to the startx problem at all. > Maybe we should check which argument are passed to ssh before starting the > xserver ? Just in case you missed it, I don't think I have a ssh server on my computer but I still have this .config/Trolltech.conf file :) This is a duplicate of #2719 or vice versa. See Also:
(none) =>
https://bugs.kde.org/show_bug.cgi?id=249217 hum seems like i miss again (like in #2719) the / & not /root. Making this one duplicate since the upstream bug is already available in # 2719 Thanks dicks for noticing :) *** This bug has been marked as a duplicate of bug 2719 *** Status:
NEW =>
RESOLVED |