Jonas Karlsson wrote:
So does it set the x bit only if an x bit already exists for the file in the user/group triplet?On Sat, 10 May 2008 10:13:00 +0200, Daniele Maccari <[EMAIL PROTECTED]> wrote:Michael Homer wrote:On 5/10/08, Daniele Maccari <[EMAIL PROTECTED]> wrote:Ok, I finally solved the problem (if right or wrong, I don't know). Attached you'll find the patch, please let me know. This way files on which current user has no permissions should be correctly managed, as well as globbing (which sudo prevents from working, since the command is first parsed by shell, and the permission problem arises).If it's unpacking with bad permissions just fix them in the hook. The directories should be g+rx. I'm puzzled as to why it wouldn't compile as root then, though. -MichaelOk, playing a bit I found out that changing opt and usr directories' permission to a+rx apparently solved the problem. In the recipe there was though a "chmod -R a+rX usr/share" command, which honestly I couldn't understand.The difrerence is that +X only sets executable bit if it is set for another group/user. This is useful for recursive chmod as it will only set executable bit for directories (allow listing) and files with executable bit set, not to all files (you probably don't want that).
Well, rpmoffset is actually used as an executable in the recipe, so I think the x bit is ok.Now permissions look like these in the sources directory drwxr-sr-x 2 macco sys 4096 2008-03-14 21:44 licenses drwxr-sr-x 3 gobo sys 4096 2008-05-10 10:03 opt drwxr-sr-x 2 macco sys 4096 2008-03-14 21:44 readmes -rwxr-xr-x 1 gobo sys 7770 2008-05-10 10:05 rpmoffset drwxr-sr-x 3 macco sys 4096 2008-03-14 21:44 RPMS -rwxr-xr-x 1 macco sys 3925 2008-03-14 21:44 update drwxr-sr-x 4 gobo sys 4096 2008-05-10 10:04 usrHere you can see that rpmoffset and update files have the executable bit set, which you probably don't want. It's not fatal for these files as they probably are textfiles, but you get the idea.
So could this be the problem in the first place? Compiling as a regular user (even if belonging to the sys group) doesn't give you permissions to list contents, and so the globbing when copying directories' contents fails. Though again, root should just behave fine, since it can do anything on everything.and Compile can easy install the program. It remains the fact, as you pointed out, that in the previous case also compiling as root gave problems. Permissions was like these: drwxr-sr-x 2 macco sys 4096 2008-03-14 21:44 licenses drwx--S--- 3 gobo sys 4096 2008-05-10 10:11 opt drwxr-sr-x 2 macco sys 4096 2008-03-14 21:44 readmes -rwxr-xr-x 1 gobo sys 7770 2008-05-10 10:11 rpmoffset drwxr-sr-x 3 macco sys 4096 2008-03-14 21:44 RPMS -rwxr-xr-x 1 macco sys 3925 2008-03-14 21:44 update drwx--S--- 4 gobo sys 4096 2008-05-10 10:11 usr Note the capitalized S for usr and opt group permissions. I can't really figure out the problem.An s/S in the group permissions means that the setguid bit is set, which will force group owner to 'sys' for each created file and subdirectory. If the S is capitalized it means that the executable (listing) bit is not set. This has the effect that although group 'sys' is enforced members in that group cannot list contents in the directories.
Attached's the recipe, for reference. Thanks everybody.
OpenOffice--2.4.0_bin--recipe.tar.bz2
Description: Binary data
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
