[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request: Copy files instead of moving if parent dir is not writable
From: "Lamarque Vieira Souza" <lamarque () kde ! org>
Date: 2012-03-27 19:13:06
Message-ID: 20120327191306.341.67388 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On March 27, 2012, 2:30 p.m., Thomas Lübking wrote:
> > Does the new patch actually *silently* skip move impossible attempts??
> > Excuse my ignorance, but why are system resources actually needed to be *moved* \
> > anywhere by a random user - what means they're now gone in their original \
> > location (and for everyone else) This does not sound as if the current move has a \
> > problem, but the design of those private activities has (single user approach -> \
> > fix that by logging him in as root and watch the project fail ;-)
>
> Lamarque Vieira Souza wrote:
> Yes, the new patch silently skips moving impossible attempts. I tested it here and \
> we do not need to move the .desktop file to add the app to the homescreen. Skipping \
> the move seems to fix the other problem described in #296808, now the containments \
> are not empty after a reboot, I still need to figure out why this change fixes that \
> problem (debugging nepomuk is not easy :-/).
> Private activities are intended to protect data from different persons, not user \
> accounts (like it usually is the case in Linux/Unix). Everybody logs in using the \
> same non-root account and to access a private activity the person must authenticate \
> yourself first. The itention is to treat a private activity as if it is different \
> user account but the kde daemons (kactivitymanager, nepomuk, kded, contourd, etc) \
> were not designed to authenticate users so we are resorting to encfs for that. With \
> encfs the person using the device must supply a password to mount the encrypted \
> folder and access the private data. One use case for that is a parent that creates \
> a "Work" activity with data from his/her work, the parent also lends the device to \
> his/her kids to play and do not want them to mess with his data, so the parent can \
> mark the activity as private and the kids will not access to the data.
> We are working on how to decide which data to move to the private folder and also \
> when move them back to the original place. In this case we do not need to move \
> .desktop files but moving files is still necessary if the file is a document \
> created by the user.
> Thomas Lübking wrote:
> > kids will not access to the data
> except for deleting them (but that is quite OT)
>
> > I still need to figure out why this change fixes that problem
> I'd say non interactive file operations will just exit with an error on a conflict.
>
> Anyway, i guess the proper layer to decide which data to copy/move/symlink is not \
> the general data management but the private activity creation, where you will \
> likely also want to break/restore file permissions (eg. if a user dir has been \
> tagged read-only, it's files should still be moved to the private activity and the \
> former status restored there)
> In general, just silently skipping impossible file operations is imo no option, \
> because even if you just copied the data instead, it remains in a pot. public \
> location what may be explicitly not wanted by explicitly attempting to move the \
> file. This could (for eg. chmod 500 directories) end up in exposing company secrets \
> as well as just your kids suddenly stumbling across your FapFolder(tm)
> except for deleting them (but that is quite OT)
Yes, that is possible.
Well, Plasma Active makes heavy use of nepomuk to hide filesystem structure, which \
means there is no easy way for the user to change file permissions. Hidding \
filesystem structure is a design decision (made before I joined the team by the way). \
We still ship Dolphin with the images but since it is reduntant compared to \
active-filebrowser (PA's file manager) I guess it will be removed in the future.
I could change the patch to move the file if either the user owns the parent \
directory or he/she has write permissions to the parent folder.
- Lamarque Vieira
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104417/#review11909
-----------------------------------------------------------
On March 27, 2012, 2:22 p.m., Lamarque Vieira Souza wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104417/
> -----------------------------------------------------------
>
> (Updated March 27, 2012, 2:22 p.m.)
>
>
> Review request for KDE Runtime and Plasma.
>
>
> Description
> -------
>
> When adding an application resource to a private activity kactivitymanager tries to \
> move the resource's .desktop file to the activity's private folder. The new \
> .desktop file is created successfully but the source file is not deleted if the \
> user does not have write permission on the file's directory. This patch detects \
> such situation and uses copy instead of move to prevent "permission denied" \
> messages for every resource being added.
>
> This addresses bug 296808.
> http://bugs.kde.org/show_bug.cgi?id=296808
>
>
> Diffs
> -----
>
> service/jobs/nepomuk/Move.h 8a8afd1
> service/jobs/nepomuk/Move.cpp 08a3cc2
>
> Diff: http://git.reviewboard.kde.org/r/104417/diff/
>
>
> Testing
> -------
>
> Works on Meego devel image. The file is copied and no error message is shown.
>
>
> Thanks,
>
> Lamarque Vieira Souza
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/104417/">http://git.reviewboard.kde.org/r/104417/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On March 27th, 2012, 2:30 p.m., <b>Thomas \
Lübking</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Does the new patch actually *silently* skip move impossible attempts?? \
Excuse my ignorance, but why are system resources actually needed to be *moved* \
anywhere by a random user - what means they're now gone in their original \
location (and for everyone else) This does not sound as if the current move has a \
problem, but the design of those private activities has (single user approach -> \
fix that by logging him in as root and watch the project fail ;-)</pre> \
</blockquote>
<p>On March 27th, 2012, 3:22 p.m., <b>Lamarque Vieira Souza</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yes, the new patch \
silently skips moving impossible attempts. I tested it here and we do not need to \
move the .desktop file to add the app to the homescreen. Skipping the move seems to \
fix the other problem described in #296808, now the containments are not empty after \
a reboot, I still need to figure out why this change fixes that problem (debugging \
nepomuk is not easy :-/).
Private activities are intended to protect data from different persons, not user \
accounts (like it usually is the case in Linux/Unix). Everybody logs in using the \
same non-root account and to access a private activity the person must authenticate \
yourself first. The itention is to treat a private activity as if it is different \
user account but the kde daemons (kactivitymanager, nepomuk, kded, contourd, etc) \
were not designed to authenticate users so we are resorting to encfs for that. With \
encfs the person using the device must supply a password to mount the encrypted \
folder and access the private data. One use case for that is a parent that creates a \
"Work" activity with data from his/her work, the parent also lends the \
device to his/her kids to play and do not want them to mess with his data, so the \
parent can mark the activity as private and the kids will not access to the data.
We are working on how to decide which data to move to the private folder and also \
when move them back to the original place. In this case we do not need to move \
.desktop files but moving files is still necessary if the file is a document created \
by the user.</pre> </blockquote>
<p>On March 27th, 2012, 4:08 p.m., <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> kids will not \
access to the data except for deleting them (but that is quite OT)
> I still need to figure out why this change fixes that problem
I'd say non interactive file operations will just exit with an error on a \
conflict.
Anyway, i guess the proper layer to decide which data to copy/move/symlink is not the \
general data management but the private activity creation, where you will likely also \
want to break/restore file permissions (eg. if a user dir has been tagged read-only, \
it's files should still be moved to the private activity and the former status \
restored there)
In general, just silently skipping impossible file operations is imo no option, \
because even if you just copied the data instead, it remains in a pot. public \
location what may be explicitly not wanted by explicitly attempting to move the file. \
This could (for eg. chmod 500 directories) end up in exposing company secrets as well \
as just your kids suddenly stumbling across your FapFolder(tm)</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> except for deleting \
them (but that is quite OT) Yes, that is possible.
Well, Plasma Active makes heavy use of nepomuk to hide filesystem structure, which \
means there is no easy way for the user to change file permissions. Hidding \
filesystem structure is a design decision (made before I joined the team by the way). \
We still ship Dolphin with the images but since it is reduntant compared to \
active-filebrowser (PA's file manager) I guess it will be removed in the future.
I could change the patch to move the file if either the user owns the parent \
directory or he/she has write permissions to the parent folder.</pre> <br />
<p>- Lamarque Vieira</p>
<br />
<p>On March 27th, 2012, 2:22 p.m., Lamarque Vieira Souza wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for KDE Runtime and Plasma.</div>
<div>By Lamarque Vieira Souza.</div>
<p style="color: grey;"><i>Updated March 27, 2012, 2:22 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">When adding an application resource to a private activity \
kactivitymanager tries to move the resource's .desktop file to the activity's \
private folder. The new .desktop file is created successfully but the source file is \
not deleted if the user does not have write permission on the file's directory. \
This patch detects such situation and uses copy instead of move to prevent \
"permission denied" messages for every resource being added.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Works on Meego devel image. The file is copied and no error message is \
shown.</pre> </td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=296808">296808</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>service/jobs/nepomuk/Move.h <span style="color: grey">(8a8afd1)</span></li>
<li>service/jobs/nepomuk/Move.cpp <span style="color: grey">(08a3cc2)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/104417/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic