BUG: 141564
Details
Details
Diff Detail
Diff Detail
- Repository
- R241 KIO
- Branch
- skip_stat
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 6259 Build 6277: arc lint + arc unit
| src/core/copyjob.cpp | ||
|---|---|---|
| 419 ↗ | (On Diff #47689) | For file permissions, 'file:' and 'trash:' use the result of QT_LSTAT, 'archive:' makes use of stat, 'sftp:' uses sftp_lstat, and smb sets UDS_ACCESS to 0500. These are the kioslaves(I found) which KDE ships and set UDS_ACCESS entry. I think using UDSEntry can be considered here. |
| src/core/copyjob.cpp | ||
|---|---|---|
| 419 ↗ | (On Diff #47689) |
Well I was completely wrong here. There are plenty other protocols that set UDS_ACCESS and someone needs to check if their UDSEntry has the correct permission since flags are being set manually. For the time being this TODO should be here. |
Comment Actions
Same result: I copy 4 folders into "/", and I get one error saying: Access denied. Could not write to "/".
Did you expect (or desire) anything else?
Comment Actions
Usually I'm the one reviewing patches for KIO, but yeah, for my own patches, who's going to review them? :-)
Comment Actions
FWIW I can confirm that it fixes the bug. I'm not an expert in KIO code but it all looks sensible enough to me, and the autotest passes.
Maybe we should land it sooner rather than later with a "you break it you buy fix it" caveat. :)
Comment Actions
Hmm, this broke PrivilegeJobTest::privilegeCopy.
If we don't give a chance to the kioslave to see the copy operation, it can't offer escalating priviledges to run the operation as root.
I guess the bug report is from before we have privilege escalation....
I think that all I can do is skip this check unless privilege escalation is disabled (but that won't help dolphin).