[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-tracker] [Bug #808] phpWebHosting - owner is replaced when
From: |
nobody |
Subject: |
[Phpgroupware-tracker] [Bug #808] phpWebHosting - owner is replaced when file is copied |
Date: |
Mon, 08 Jul 2002 23:57:23 -0400 |
=================== 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