[Phpgroupware-tracker] [Bug #808] phpWebHosting - owner is replaced when file is copied

[nobody]

=================== BUG #808: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=808&group_id=509

Changes by: Jason Wies <address@hidden>
Date: 2002-Jul-09 03:57 (UTC)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Invalid
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
The behavior you describe as a bug is in fact the correct behavior.  It is the 
same in Unix.  Take this example:

address@hidden:~$ ls -l /bin/bash
-rwxr-xr-x    1 root     root       511400 Apr  8 12:07 /bin/bash
address@hidden:~$ cp /bin/bash ~/bash
address@hidden:~$ ls -l ./bash
-rwxr-xr-x    1 user    user      511400 Jul  8 20:45 ./bash

You wouldn't expect the file to be owned by root still, as that would be a 
security problem.  In a groupware setting, take this example:

Admins use /home/Admins/howto/ as a read-only repository for documentation.  
They have a file /home/Admins/howto/change_your_password.  Now Mr. Baduser, who 
wishes to trick everyone into typing their password into his page on a another 
site, copies change_your_password to /home/Default, edits it to point to his 
site, and starts point users to it, asking them to change their password.  With 
your patch, the file would appear to be official as it would be owned by 
'Admins' still.  The correct way to handle it is to change the owner to the 
less privileged 'baduser', or the group 'Default', since 'baduser' has access 
to that group.

I think the confusion might come from the fact that when you initially moved 
the file from /home/Admins, it was still owned by Admins.  This is because you 
were moving it FROM /home/Admins, so you were acting in the role of Admin.  The 
solution is to have a interface to change file ownership and permissions, which 
we should have anyway for other reasons.  Also we might prompt them when moving 
the file, asking 'Who should this file be owned by?', with the appropriate 
default chosen for them.



=================== BUG #808: FULL BUG SNAPSHOT ===================


Submitted by: None                      Project: phpGroupWare                   
Submitted on: 2002-Jul-05 12:42
Category:  filemanager                  Bug Group:  0.9.14 release              
Severity:  5 - Major                    Priority:  None                         
Resolution:  Invalid                    Assigned to:  Zone                      
Status:  Closed                         Platform Version:  Linux - RedHat       
Reproducibility:  Every Time            

Summary:  phpWebHosting - owner is replaced when file is copied

Original Submission:  In phpWebHosting, when a file is copied from a folder 
owned by X, the file's owner is replaced by X. 

Sample steps to reproduce this bug:
1.you need full read/write access to groups Admins and Default
2.go to Admins' home folder
3.create or upload a file; it's owner is "Admins"
4.move this file to Default's home folder
5.goto Default's home folder
6.create a sub-folder named Temp
7.copy the file to Temp folder
8.goto Temp folder
9.the owner of the copy in Temp is replaced by "Default"

Follow-up Comments
*******************

-------------------------------------------------------
Date: 2002-Jul-09 03:57             By: Zone
The behavior you describe as a bug is in fact the correct behavior.  It is the 
same in Unix.  Take this example:

address@hidden:~$ ls -l /bin/bash
-rwxr-xr-x    1 root     root       511400 Apr  8 12:07 /bin/bash
address@hidden:~$ cp /bin/bash ~/bash
address@hidden:~$ ls -l ./bash
-rwxr-xr-x    1 user    user      511400 Jul  8 20:45 ./bash

You wouldn't expect the file to be owned by root still, as that would be a 
security problem.  In a groupware setting, take this example:

Admins use /home/Admins/howto/ as a read-only repository for documentation.  
They have a file /home/Admins/howto/change_your_password.  Now Mr. Baduser, who 
wishes to trick everyone into typing their password into his page on a another 
site, copies change_your_password to /home/Default, edits it to point to his 
site, and starts point users to it, asking them to change their password.  With 
your patch, the file would appear to be official as it would be owned by 
'Admins' still.  The correct way to handle it is to change the owner to the 
less privileged 'baduser', or the group 'Default', since 'baduser' has access 
to that group.

I think the confusion might come from the fact that when you initially moved 
the file from /home/Admins, it was still owned by Admins.  This is because you 
were moving it FROM /home/Admins, so you were acting in the role of Admin.  The 
solution is to have a interface to change file ownership and permissions, which 
we should have anyway for other reasons.  Also we might prompt them when moving 
the file, asking 'Who should this file be owned by?', with the appropriate 
default chosen for them.

-------------------------------------------------------
Date: 2002-Jul-08 15:05             By: gisu
I've submitted patch #391 to fix this.






No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=808&group_id=509