Filemanager Bug#1817

Hans-Jurgen_Tappe 2008-11-12 21:13:33 UTC #1

Hi Ralf!

About #1817 - Revoked access rights do not restrict read access:
You are right, it’s not easy to reproduce this. I have digged a bit more
and found the following:
For new groups, user directories and new-born directories (like your
/pub example), revoked permissions really result in zery-Byte downloads
in webdav.php.

Still, the problem persists in the group directories which I imported
from version 1.4, the zero-permission files are still displaying as
links and are downloadable. What could cause this problem (some old ID
stuff?) and how can I help debugging this (enter some debug code somewhere)?

Some other question I have is:

Why does Konqueror always show file permissions as “-rw-------”?
Why do “----------” files download as zero-Byte file? I’d expect a 401
or 403 error?

Best regards,
Hans-Jürgen

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Ralf_Becker_6 2008-11-13 07:11:02 UTC #2

Hi Hans-Jürgen,

Hans-Juergen Tappe schrieb:

Hi Ralf!

About #1817 - Revoked access rights do not restrict read access:
You are right, it’s not easy to reproduce this. I have digged a bit more
and found the following:
For new groups, user directories and new-born directories (like your
/pub example), revoked permissions really result in zery-Byte downloads
in webdav.php.

Still, the problem persists in the group directories which I imported
from version 1.4, the zero-permission files are still displaying as
links and are downloadable. What could cause this problem (some old ID
stuff?) and how can I help debugging this (enter some debug code somewhere)?

I think you still have an extended ACL, which overwrites the (not
existing) posix rights.

Some other question I have is:

Why does Konqueror always show file permissions as “-rw-------”?

Konqueror with webdav:// protocol shows only some default rights, as
standard WebDAV does not transmit permissions and I have not yet
implemented the WebDAV ACL extension (and Konq might not understand them
either). Our WebDAV class (extended from PEAR HTTP_WebDAV_Server sends
for non-readable files a mime type ‘application/x-non-readable’, but
Konq seems to have no idea what that means.

Why do “----------” files download as zero-Byte file? I’d expect a 401
or 403 error?

That’s a good question, I also wondered.
I checked the code and it’s a - now fixed - problem in the PEAR class.

Ralf

Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
cell +49 (0) 170 7815917
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

Geschäftsführer Andre Keller, Nigel John Vickers,
Gudrun K. Müller und Ralf Becker
Registergericht Kaiserslautern HRB 12087

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Hans-Jurgen_Tappe 2008-11-13 07:33:31 UTC #3

Hi!

Ralf Becker schrieb:

Still, the problem persists in the group directories which I imported
from version 1.4, the zero-permission files are still displaying as
links and are downloadable. What could cause this problem (some old ID
stuff?) and how can I help debugging this (enter some debug code somewhere)?
I think you still have an extended ACL, which overwrites the (not
existing) posix rights.

What could cause the “extended permissions”?
I am not in superuser mode and for the rest of the files, the posix ACLs
obviously work.
Do you have any idea, what I could check or what might have happened
during the 1.4 to 1.6 upgrade?
I might try to re-do the upgrade with the current codebase, maybe it
upgrades “cleaner” now?

Best regards,
Hans-Jürgen

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Ralf_Becker_6 2008-11-13 07:48:18 UTC #4

You can check the extended ACL in the respective tab in the preferences
popup of the file or directory.

The upgrade creates eacl’s when updating from 1.4, as posix rights alone
are not sufficient for the old rights.

Dont think re-running the upgrade helps much.

Ralf

Hans-Juergen Tappe schrieb:

Hi!

Ralf Becker schrieb:

Still, the problem persists in the group directories which I imported
from version 1.4, the zero-permission files are still displaying as
links and are downloadable. What could cause this problem (some old ID
stuff?) and how can I help debugging this (enter some debug code somewhere)?
I think you still have an extended ACL, which overwrites the (not
existing) posix rights.

What could cause the “extended permissions”?
I am not in superuser mode and for the rest of the files, the posix ACLs
obviously work.
Do you have any idea, what I could check or what might have happened
during the 1.4 to 1.6 upgrade?
I might try to re-do the upgrade with the current codebase, maybe it
upgrades “cleaner” now?

Best regards,
Hans-Jürgen

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
cell +49 (0) 170 7815917
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

Geschäftsführer Andre Keller, Nigel John Vickers,
Gudrun K. Müller und Ralf Becker
Registergericht Kaiserslautern HRB 12087

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Hans-Jurgen_Tappe 2008-11-13 09:04:08 UTC #5

Hi!

Ralf Becker schrieb:

You can check the extended ACL in the respective tab in the preferences
popup of the file or directory.

The extended ACL tab only shows up for the directory, not for the file
(if they apply due to inheritance, they should show up, please, at least
informative with the inherited ACL set).

But I cannot delete extended ACLs (even if I just added them anew) for
groups (while I can delete extended ACLs for users), even as a
superuser. there’s no entry in the error log, so what’s the problem with
removing the extended ACLs…?

Thanks,
Hans-Jürgen

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Ralf_Becker_6 2008-11-13 11:25:12 UTC #6

Hi Hans-Juergen,

Hans-Juergen Tappe schrieb:

Hi!

Ralf Becker schrieb:

You can check the extended ACL in the respective tab in the preferences
popup of the file or directory.

The extended ACL tab only shows up for the directory, not for the file
(if they apply due to inheritance, they should show up, please, at least
informative with the inherited ACL set).

Please open a feature request, I’m currently too busy getting the bugs
fixed for the final release next week.

But I cannot delete extended ACLs (even if I just added them anew) for
groups (while I can delete extended ACLs for users), even as a
superuser. there’s no entry in the error log, so what’s the problem with
removing the extended ACLs…?

The problem is simple: the delete button transmits fs_id and owner
delimited with a dash. If owner is (always) a group the id is negative
and exploding by ‘-’ removes the owner.

It’s fixed now.

Thanks for your through testing

Ralf

Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
cell +49 (0) 170 7815917
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

Geschäftsführer Andre Keller, Nigel John Vickers,
Gudrun K. Müller und Ralf Becker
Registergericht Kaiserslautern HRB 12087

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Hans-Jurgen_Tappe 2008-11-13 11:51:59 UTC #7

Hi Ralf!

Ralf Becker schrieb:

Hans-Juergen Tappe schrieb:

Ralf Becker schrieb:

You can check the extended ACL in the respective tab in the preferences
popup of the file or directory.
The extended ACL tab only shows up for the directory, not for the file
(if they apply due to inheritance, they should show up, please, at least
informative with the inherited ACL set).
Please open a feature request, I’m currently too busy getting the bugs
fixed for the final release next week.

OK, done.

But I cannot delete extended ACLs (even if I just added them anew) for
groups (while I can delete extended ACLs for users), even as a
superuser. there’s no entry in the error log, so what’s the problem with
removing the extended ACLs…?
The problem is simple: the delete button transmits fs_id and owner
delimited with a dash. If owner is (always) a group the id is negative
and exploding by ‘-’ removes the owner.
It’s fixed now.

Thank you.

Thanks for your through testing

Well, my testing helps because of your responsiveness for fixes.
I’ve some environments waiting for the new release - you will have
noticed their special interests.

Best regards,
Hans-Jürgen

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers