|
Bugzilla – Full Text Bug Listing |
| Summary: | StoreBackup: Permissions broken (no execute permission) | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Christian Boltz <suse-beta> |
| Component: | ConsoleApps | Assignee: | Matthias Eckermann <mge> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | forgotten_7L3tOtZIov |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | storeBackup.spec.diff | ||
No activity on this bug since two weeks :-( Hello?! Accepted, it's a bug in the spec-file. As workaround chmod 755 /usr/lib/storeBackup/bin/* should be fine. Working on. Thanks for working on this (BTW, I already knew chmod ;-) Please don't forget to chmod the directories too ;-) Hello? BTW, /usr/share/doc/packages/storeBackup has wrong permissions, too. Created attachment 60408 [details]
storeBackup.spec.diff
Attached please find a proposed patch for the storebackup spec file. This should fix the directory permissions and a few other quirks.
FWIW, I added an updated RPM to http://lenz.homelinux.org/RPMs/10.0-i386/ now. Thanks for the patch (applied) and your patience - so short MgE Approved for 10.0 - Maintenance-Tracker-3398 3398 submitted. FIXED. MgE Thanks ;-) Question: Is this also fixed for 10.1? beta1 contains a broken package... yes, sure:-) I also submitted the patched spec-file to 10.1-beta, i.e. one of the next betas should have it, ... released *** Bug 165030 has been marked as a duplicate of this bug. *** |
I just found that StoreBackup does not work in 10.0: # storeBackup bash: /usr/bin/storeBackup: Permission denied The reason is quite simple - the StoreBackup directories and scripts don't have the "x" permission set. (It seems someone run "chmod -R 644" accidently.) This means a normal user can't even cd into /usr/lib/storeBackup. And, of course, nobody can run StoreBackup :-( I would highly recommend to prepare a YOU update for this. For your convience, here's the list of permissions as set in the RPM. Please note that /etc/cron.daily/storebackup is the only file with x permissions... # rpm -qlv storeBackup | awk '{print $1" "$9" "$10" "$11}' -rwxr-xr-x /etc/cron.daily/storebackup drw-r--r-- /etc/storebackup.d lrwxr-xr-x [... several symlinks ...] drw-r--r-- /usr/lib/storeBackup drw-r--r-- /usr/lib/storeBackup/bin -rw-r--r-- /usr/lib/storeBackup/bin/llt -rw-r--r-- /usr/lib/storeBackup/bin/multitail.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackup.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackupConvertBackup.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackupDel.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackupMount.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackupRecover.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackupVersions.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackup_du.pl -rw-r--r-- /usr/lib/storeBackup/bin/storeBackupls.pl drw-r--r-- /usr/lib/storeBackup/lib -rw-r--r-- /usr/lib/storeBackup/lib/checkObjPar.pl -rw-r--r-- /usr/lib/storeBackup/lib/checkParam.pl -rw-r--r-- /usr/lib/storeBackup/lib/dateTools.pl -rw-r--r-- /usr/lib/storeBackup/lib/evalTools.pl -rw-r--r-- /usr/lib/storeBackup/lib/fileDir.pl -rw-r--r-- /usr/lib/storeBackup/lib/forkProc.pl -rw-r--r-- /usr/lib/storeBackup/lib/humanRead.pl -rw-r--r-- /usr/lib/storeBackup/lib/prLog.pl -rw-r--r-- /usr/lib/storeBackup/lib/readKeyFromFile.pl -rw-r--r-- /usr/lib/storeBackup/lib/splitLine.pl -rw-r--r-- /usr/lib/storeBackup/lib/storeBackupLib.pl -rw-r--r-- /usr/lib/storeBackup/lib/tail.pl -rw-r--r-- /usr/lib/storeBackup/lib/version.pl drw-r--r-- /usr/share/doc/packages/storeBackup -rw-r--r-- /usr/share/doc/packages/storeBackup/ [... several files ...] The files in .../bin/... should all be executable. .../lib/fileDir.pl is executable in 9.3's package, but I'm not sure about that one. Of course all directories should get a "x" bit too.