**** BEGIN LOGGING AT Mon Mar 21 02:59:57 2011 Mar 21 03:16:07 philipp64: you use x86 ? Mar 21 03:17:06 philipp64: are there kernel version mismatch problems with clean checkout? (I want to ask before doing dirclean and rebuilding) Mar 21 03:22:41 nbd * r26251 /trunk/package/mac80211/patches/570-mac80211_initialize_last_rx.patch: Mar 21 03:22:42 mac80211: initialize the last rx time when creating a station Mar 21 03:22:42 should hopefully finally take care of the nasty reassociation issues which showed up as Mar 21 03:22:42 Jan 1 00:51:10 OpenWrt daemon.info hostapd: wlan0: STA 00:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity Mar 21 03:22:42 right after associating, leading to an immediate disconnect. Mar 21 03:22:42 Will probably fix #8343, #8830 and others. Mar 21 03:25:16 nbd: ping Mar 21 03:25:29 pong Mar 21 03:25:49 are you planning to add any more mac80211/ath9k patches? if not I'm prepping to build right now Mar 21 03:26:17 no, i'll backport that last patch to backfire and then i'll probably go to sleep Mar 21 03:26:23 ok Mar 21 03:26:24 thanks Mar 21 03:26:51 as always I'll let you know Mar 21 03:27:02 thanks Mar 21 03:27:16 nbd * r26252 /branches/backfire/package/mac80211/patches/562-mac80211_initialize_last_rx.patch: mac80211: backport the inactivity timeout fix from r26251 Mar 21 03:28:41 this last bug that i fixed was so trivial that it really annoys me that i didn't find it earlier ;) Mar 21 03:35:10 haha I hear that Mar 21 03:38:11 build #78 of iop32x is complete: Failure [failed shell compile_6] Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/78 Mar 21 03:49:18 "complete Failure" :-) Mar 21 05:56:22 cshore * r26253 /trunk/package/hotplug2/files/hotplug2.rules: Mar 21 05:56:22 [package] hotplug2: Added zaptel subsystem to /etc/hotplugs2.rules so that the Mar 21 05:56:22 zaptel kernel module package only needs to had a script to create the correct Mar 21 05:56:22 device nodes (default names differ from what all apps that use zaptel actually Mar 21 05:56:22 use, so a script is necessary). Mar 21 06:10:17 cshore: pong Mar 21 06:10:30 xMff: forgot Mar 21 06:10:37 :D Mar 21 06:45:13 jow * r26254 /packages/devel/binutils/Makefile: [packages] binutils: fix linking to libiberty (#9048) Mar 21 06:48:28 jow * r26255 /trunk/package/ncurses/Makefile: [package] ncurses: install ncurses5-config and ncursesw5-config (#9044) Mar 21 07:17:41 cshore: btw, we still need some clean way to reenable the overlay Mar 21 07:17:46 in extroot Mar 21 10:39:50 build #85 of x86 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/85 Mar 21 11:56:07 xMff: i have a patch for libX11 i grabbed from ubuntu that lets it build with modern groff's Mar 21 11:57:06 http://www.personaltelco.net/~russell/libx11.patch Mar 21 11:57:37 (or anyone else for that matter) Mar 21 12:08:58 build #77 of ep93xx is complete: Failure [failed shell_9] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/77 Mar 21 12:11:07 Kaloz: ping? I don't suppose that you could help me reset my OpenWrt trac password? n_b_d (to avoid highlighting him :) ) suggested that I sent you a new hashed password (already done) Mar 21 12:22:30 russell--: thank you, I'll take a look later Mar 21 12:25:55 Kaloz: see pm Mar 21 14:48:19 Does anyone here know the proper way to obtain the PYTHON_SITE_DIR from python utility? Mar 21 14:58:37 ryd: ping Mar 21 15:02:57 Kaloz: ping Mar 21 15:06:54 build #93 of pxcab is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/93 Mar 21 15:07:02 build #94 of ramips is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/94 Mar 21 15:20:22 build #92 of ps3 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/92 Mar 21 15:22:00 build #86 of ar7 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/86 Mar 21 15:22:29 build #86 of sibyte is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/86 Mar 21 15:29:39 uh wtf Mar 21 15:41:26 build #106 of s3c24xx is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/106 Mar 21 15:43:45 xMff: I know...it's on my todo list, unfortunately this past weekend I had family up (well it was good for me, no so much for openwrt though). Mar 21 15:43:58 cshore: ;) Mar 21 15:44:19 cshore: no worries, basically we need a simple init script action which just wipes all md5sums and tells the user to reboot Mar 21 15:44:56 implemented with EXTRA_COMMANDS (http://wiki.openwrt.org/doc/techref/initscripts) Mar 21 15:45:53 so a user can run /etc/init.d/fstab overlay-enable Mar 21 15:46:05 jow_laptop: thanks for pointing that out...I didn't know about EXTRA_COMMANDS Mar 21 15:47:36 I assume eventually we should try to do the stuff we talked about with the binaries and things (to try to get the overlay to a sane state without manual intervention) Mar 21 15:52:31 jow_laptop: I'll see about doing that either tonight or wednesday night...right now I'm working, but have my chat up (thought I try not to be too distracted) Mar 21 15:57:33 hehe, same here Mar 21 16:29:59 build #80 of au1000 is complete: Exception [exception failed slave lost shell shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/80 Mar 21 16:30:00 build #113 of brcm63xx is complete: Exception [exception failed slave lost shell shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/113 Mar 21 16:30:02 build #79 of iop32x is complete: Exception [exception failed slave lost shell shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/79 Mar 21 16:30:05 build #95 of ramips is complete: Exception [exception failed slave lost shell shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/95 Mar 21 16:48:43 cshore * r26256 /packages/net/yate/Makefile: Mar 21 16:48:43 [net] Telephony: Yate: Fixed build problems that prevented server modules from Mar 21 16:48:43 loading. (Must not use libtool fixup). Also added copy of SNMP files to Mar 21 16:48:43 /usr/share/yate/data as is expected when the ysnmpagent module is installed. Mar 21 16:48:43 Also switched to using PKG_INSTALL instead of copying object from source/build Mar 21 16:48:43 tree. Mar 21 16:55:26 thepeople * r26257 /trunk/target/linux/adm5120/base-files/lib/upgrade/platform.sh: sysupgrade works on the wp54 Mar 21 17:06:23 build #79 of etrax is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/79 Mar 21 17:09:35 cshore: if it fails with PKG_FIXUP something is fishy about it Mar 21 17:11:54 xMff: It can't find stuff under /usr/lib/yate/server (the base dir is /usr/lib/yate) when libtool is in use Mar 21 17:13:19 xMff: the build itself succeeds Mar 21 17:18:00 build #103 of ubicom32 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/103 Mar 21 17:28:18 build #74 of octeon is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/74 Mar 21 17:30:54 xMff: btw, in case you're wondering, I convinced work to let me put yate in openwrt so that we could have other eyes on it, along with the zaptel driver stuff so that I can use yate with my fxs/fxo on a old PC for devel/testing of the system I'm working on for them. Mar 21 17:31:02 build #101 of orion is complete: Failure [failed compile_1] Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/101 Mar 21 17:31:36 okay, is it as complex as the asterisk or freeswitch stuff? Mar 21 17:39:59 jow * r26258 /trunk/tools/ipkg-utils/patches/190-preserve_permissions.patch: [tools] ipkg-utils: utilize the tar -p flag to preserve permissions (#7667) Mar 21 17:41:25 jow * r26259 /trunk/include/image.mk: [include] image.mk: only upgrade permissions instead of overwriting, utilize tar -p flag for targz image targets (#7667) Mar 21 17:41:27 xMff: It's similar but not as messy as freeswitch (haven't really look at asterisk except a quick glance) as far as the build system goes Mar 21 17:42:47 xMff: the freeswitch build system glows in the dark and will cause you to glow in the dark Mar 21 17:43:21 ;) Mar 21 17:44:22 it also seems to have been busted recently Mar 21 17:45:10 but unless work wants me to try freeswitch I can't work on it (and don't particularly want to anyway) Mar 21 17:45:59 I think nobody expects you to Mar 21 17:47:02 I don't think I'm expected to, but it was my package for a while, so I still feel somewhat reponsible Mar 21 18:43:38 build #108 of at91 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/108 Mar 21 19:19:30 xMff: r26259: it looks like chmod's +X feature would have helped make this more concise. +X is like +x but will set the execute bit for u/g/o as specified if the execute bit is currently set for anyone. Mar 21 19:20:03 markmentovai: oh, well I just tried to be conservative (bsd, osx, ...) Mar 21 19:20:30 capital X is standard Mar 21 19:20:56 mac chmod supports it for sure, and i'd be amazed if the bsds didn't Mar 21 19:25:09 ok Mar 21 19:36:05 markmentovai/xMff: both freebsd and mac os x support +X Mar 21 19:36:15 * ermo checked man pages Mar 21 19:37:53 netbsd, openbsd and dragonfly bsd as well Mar 21 19:37:57 so +X is safe. Mar 21 19:38:16 or, well, I haven't checked solaris and AIX yet ... Mar 21 19:38:51 those aren ot exactly supported anyway Mar 21 19:39:23 my thoughts exactly Mar 21 19:39:52 markmentovai: just so we're clear: how would you change the command again? Mar 21 19:40:17 chmod +X,+W foo ? Mar 21 19:40:28 you could fold the two find bleh -type f invocations into a single one Mar 21 19:40:39 you could really even get rid of -type f/-type d and just have a single invocation Mar 21 19:41:54 or have a single one that specifies f or d Mar 21 19:43:55 my brain is slow right now, care to write an example? Merging both finds sounds like a neat efficiency gain for larger rootfses Mar 21 19:44:00 let's see: -type d will have +0100 set Mar 21 19:44:07 otherwise, it's not of much use Mar 21 19:51:02 - $(FIND) $(TARGET_DIR) -not -name 'ssh_host*' -print0 | $(XARGS) -0 chmod u+rwX,g+rX,o+rX Mar 21 19:51:58 that will normalize executable files and directories, while not touching 'ssh_host*' Mar 21 19:52:07 markmentovai: ^^ like that? Mar 21 19:52:36 yeah. i actually usually write a+rX,u+w Mar 21 19:52:46 neat Mar 21 19:52:52 sorry, was afk for a moment, i would have written the above a few minutes ago Mar 21 19:53:07 - $(FIND) $(TARGET_DIR) -not -name 'ssh_host*' -print0 | $(XARGS) -0 chmod a+rX,u+w Mar 21 19:53:23 or explicitly drop the w bit on g and o, a+rX,u+w,go-w Mar 21 19:53:29 that's how i usually normalize permissions on large trees Mar 21 19:53:45 careful of chmod poking through symbolic links with that invocation Mar 21 19:53:49 you might want to exclude type l Mar 21 19:54:31 - $(FIND) $(TARGET_DIR) -not -type l -not -name 'ssh_host*' -print0 | $(XARGS) -0 chmod a+rX,u+w,go-w Mar 21 19:54:37 that's hot Mar 21 19:54:56 * ermo tries it before foisting it upon the unwashed masses Mar 21 19:55:28 surely, there must be other files that should not be world readable ... Mar 21 19:55:48 if we begin to assume that "I'm logged in" is not always == I've got root Mar 21 19:56:05 well the current changes where an intermediate measure Mar 21 19:56:07 * ermo promptly develops a headache Mar 21 19:56:25 in the end there is some kind of permission override required Mar 21 19:56:40 which has to be developed and integrated into mksquashfs first Mar 21 19:56:47 its nothing you can solve programmatically Mar 21 19:57:11 if $(TARGET_DIR) is inside another directory that's more restrictive, that's a pretty good mitigation Mar 21 19:57:48 markmentovai: can you unpack that statement by example? Mar 21 20:00:10 STAGING_DIR=$(dirname "${TARGET_DIR}"); mkdir -m 700 "${STAGING_DIR}"; mv "${TARGET_DIR}" "${STAGING_DIR}/"; TARGET_DIR="${STAGING_DIR}/$(basename "${TARGET_DIR}")"; proceed Mar 21 20:04:58 markmentovai: in the context of Image.mk, how would that look? Mar 21 20:05:14 gimme a sec to pull up image.mk Mar 21 20:06:15 * ermo tries out the modified find statement in the meantime Mar 21 20:12:05 ermo: i suspect the easiest way to go would be to introduce TARGET_PARENT_DIR in rules.mk, set to $(TARGET_ROOTFS_DIR)/intermediate, and then set TARGET_DIR in rules.mk to $(TARGET_PARENT_DIR)/root-$(BOARD). i'm having a hard time finding for sure where TARGET_DIR is supposed to be created, though. Mar 21 20:12:38 i'm afraid that it can be created by any of a number of "mkdir -p"s Mar 21 20:14:13 this may prove to be more trouble than it's worth. Mar 21 20:14:30 at least consolidating the finds doesn't make anything worse. Mar 21 20:15:36 markmentovai: just so that we're on the same page (You may be ahead of me here), but you want to introduce an extra directory that only has 0700 permissions (u=rwx) for ... what, exactly? Mar 21 20:15:55 i thought that was the problem you were trying to solve above. i may have misundersood. Mar 21 20:16:10 i thought you were saying you didn't necessarily want world-readable files on the system building the image Mar 21 20:16:17 I was Mar 21 20:16:45 it's the implications that I don't quite follow -- iow, I need help to unpack your proposal and its implications Mar 21 20:16:46 sticking them all in an 0700 directory will keep anyone other than the owner out of those files Mar 21 20:17:10 Ah, ok. I was thinking of it in another context Mar 21 20:17:20 if i'm not the owner, i can't cd into or beyond the 0700 directory, because i don't have the x-bit on one of the components in the tree i'm trying to traverse Mar 21 20:17:36 what was your context? Mar 21 20:17:56 as in "whatever we copy in here will be stripped of !u permission bits" Mar 21 20:18:16 markmentovai: assume that we have package X and Y Mar 21 20:18:35 package X carefully sets its permissions as part of its build processs Mar 21 20:18:55 package Y has no sensitive files that need specific permissions Mar 21 20:19:41 I would like to see that the sensitive parts of package X is not normalized, but package Y is Mar 21 20:20:08 markmentovai: but as I understand it, this is not what your proposal is about? Mar 21 20:20:27 no, i understood your description of the problem differently. i see. Mar 21 20:20:44 your proposal was to cordon off *everything* sensitive to a different dir, right? Mar 21 20:20:58 you're saying "what if there are files other than ssh_host* that are sensitive?" Mar 21 20:20:59 right Mar 21 20:21:04 precisely :) Mar 21 20:21:22 presumably, packages that are designed with security in mind know which files are sensitive Mar 21 20:21:35 right. it's something that would need to be handled on a package-by-package basis. Mar 21 20:21:44 (or which files need their SUID set, as was the case with sudo) Mar 21 20:21:48 sure Mar 21 20:22:55 so, xMff was pointing out that the -not -name 'ssh_host*' was an interim measure until it can be done 'properly' (for a suitable definition of 'properly) Mar 21 20:23:25 ah, i misunderstood that part Mar 21 20:23:33 as I understood it -- but then it sounded like you had a really neat idea, which was why I asked :) Mar 21 20:23:41 heh Mar 21 20:35:37 xMff: the find syntax we use currently is not POSIX compliant, btw. Mar 21 20:36:02 xMff: why are bothering to normalize in the first place? Mar 21 20:36:31 I mean, if we're not touching SUID/SGID now, we're assuming that packages are sane to begin with ... Mar 21 20:36:59 * ermo is afraid that this will end up being a can of worms Mar 21 20:38:47 markmentovai: strictly speaking, why would we do 'u+w'? Mar 21 20:39:28 again, packages would probably have set that ... Mar 21 20:39:42 * ermo is making an awful lot of assumptions Mar 21 20:39:54 best just leave it mostly as it was Mar 21 20:40:37 i suppose it's not strictly necessary, it's more of a matter of policy than anything else. the question is "is that package dropping w because it really shouldn't have w, or just because it can?" Mar 21 20:40:50 perl, for example, is notorious for dropping w just because it can Mar 21 20:41:58 there's no better reason for strict.pm to not be writable than there is for ld.so to not be writable, and in fact, you could make the (probably bogus) argument that ld.so ought not be writable even moreso than any other file on the system Mar 21 20:42:28 yeah, I think what it really boils down to that you need to make a per package decision and put packages in one of two buckets: 1) has SUID/SGID bit set (should be audited) and 2) doesn't have any SUID/SGID bit set and can be left alone Mar 21 20:42:58 it certainly does sound like something that would need per-package attention Mar 21 20:43:18 markmentovai: fwiw, my original patch avoided normalizing stuff with its SUID set Mar 21 20:43:35 * ermo revisits that idea Mar 21 20:43:40 ah, i didn't see that Mar 21 20:43:54 would be a quick tweak to the find, though Mar 21 20:44:45 yeah Mar 21 20:45:00 the linux find by default does not follow symlinks Mar 21 20:45:17 but ! -type l is probably still a good idea Mar 21 20:46:40 ermo: it doesn't follow, but it finds them Mar 21 20:46:45 find /lib -maxdepth 1 -ls | grep ld- Mar 21 20:47:20 chmod will operate on the target of a link, so if you gave those links to chmod, you might even be operating on files outside of ${TARGET_DIR} Mar 21 20:47:45 so ! -type l is still a good idea Mar 21 20:47:54 of course Mar 21 20:49:40 some chmods have -h to not resolve a symlink's target, but it's nonstandard, linux' doesn't have that feature, and for it to be meaningful the permission bits need to make sense on symbolic links, which isn't even portable, so...yeah...easier to use ! -type l Mar 21 20:50:07 worried about other special files? |-type f or -type d|? Mar 21 20:50:31 build #92 of ppc44x is complete: Exception [exception failed slave lost shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/ppc44x/builds/92 Mar 21 20:50:32 build #85 of uml is complete: Exception [exception failed slave lost shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/85 Mar 21 20:50:34 build #86 of x86 is complete: Exception [exception failed slave lost shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/86 Mar 21 20:50:37 build #31 of lantiq is complete: Exception [exception failed slave lost shell_13 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/lantiq/builds/31 Mar 21 20:51:09 markmentovai: but if we're not going to touch SUID/SGID/sticky bits, we might as well use a=rX,u+w,go-w ? Mar 21 20:51:39 uh maybe not Mar 21 20:51:58 * ermo considers e.g. /tmp Mar 21 20:52:19 this happens before /tmp, which has its own special chmod, right? Mar 21 20:52:29 not sure tbh Mar 21 20:52:55 we're looking at Image/mkfs/prepare/default, right? Mar 21 20:53:08 chmod 777 /tmp is the last thing that happens in there Mar 21 20:53:12 we are now, at any rate :) Mar 21 20:53:15 heh Mar 21 20:55:31 markmentovai: I can't find it... wonder what I'm missing Mar 21 20:56:03 ermo: if you use the a= form, you drop suid/sgid, which i thought r26259 was trying to fix Mar 21 20:56:30 ermo: https://dev.openwrt.org/browser/trunk/include/image.mk?rev=26259#L140 Mar 21 20:56:33 line 146 Mar 21 20:56:39 ah Mar 21 20:58:03 markmentovai: yes, my point was that we could filter out stuff with its SUID/SGID/stick bits set and treat that differently Mar 21 20:58:10 sure Mar 21 20:58:26 my 1st patch just didn't touch that stuff and normalized everything else Mar 21 20:58:38 in that case, the go-w is extraneous; just use a=rX,u+w Mar 21 20:58:38 i.e. /etc/sudoers was left at 0440 Mar 21 20:58:59 that was a bad example, actually Mar 21 21:01:07 what if we had a test that doesn't normalize if stuff isn't world-readable in the package? Mar 21 21:01:12 build #75 of mpc52xx is complete: Failure [failed shell compile_4] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/75 Mar 21 21:02:07 again, this might kind of defeat the purpose of the normalization in the first place... Mar 21 21:02:24 what to do, what to do Mar 21 21:06:32 markmentovai: this is the original ticket https://dev.openwrt.org/ticket/7667 Mar 21 21:08:08 ermo: sorry, was out for dinner. I suppose we normalize because it is a good idea (tm) Mar 21 21:08:29 ermo: i see. so at least the way things are since xMff checked this in, the suid/sgid problem is fixed Mar 21 21:09:00 yeah, upgrading permissions instead of setting them was the least intrusive approach Mar 21 21:09:21 actually handling less permissive combinations correctly is a lot of work and not be done with a few single line changes Mar 21 21:10:14 but it still means that some non-world-readable files now become world readable; /etc/shadow- comes to mind. And if that exists, it's probably does so for a reason... Mar 21 21:10:25 s/now/still/ Mar 21 21:11:01 I did not introduce something that wasn't this way before Mar 21 21:11:07 true Mar 21 21:11:16 just changed it in such a way that suid/sgid etc. are not touched Mar 21 21:13:18 in that case, doing a single-liner is probably just as good Mar 21 21:14:04 yes, until we implement a good robust way to convey permissions (and ownership) into the final rootfs Mar 21 21:14:35 some could check whether those fixups are actually needed anymore Mar 21 21:14:52 they're from a time before we ensured a umask of 0022 for building Mar 21 21:21:50 xMff: there's a larger question of worthwhile security here Mar 21 21:22:05 yeah Mar 21 21:22:36 I mean, for a 'default' build (router, physical access implies root can be achieved), it might not make a lot of sense to focus extensively on security Mar 21 21:22:57 I think we all agree on the fact Mar 21 21:23:10 its just hard to implement right Mar 21 21:23:15 ;) Mar 21 21:23:56 ermo: but the thing is openwrt is a lot more than a basic router os Mar 21 21:23:58 so whether the sudo-package retains the SUID on the sudo binary or whether /etc/shadow- is not world readable might not be too important Mar 21 21:24:04 cshore: Oh, I agree. Mar 21 21:24:21 ermo: so I think we need to solve the permissions thing eventually Mar 21 21:24:23 I'm making the point that keeping permissions make more sense in some scenarios than others Mar 21 21:24:47 and for devices using a 4-8 MB squashfs flash image, it might be overkill in the first place. Mar 21 21:25:02 and what we're discussing now is the squashfs/jffs scenario Mar 21 21:25:17 the tar.gz. part keeps permissions now Mar 21 21:25:28 no normalization going on there as far as I can tell Mar 21 21:25:31 ermo: well I think it's useful even then, but not keeping permissions, but instead setting overrides in the package Mar 21 21:25:46 ermo: I think 'keeping' permissions is a lost cause Mar 21 21:25:47 cshore: thats the plan Mar 21 21:26:06 cshore: but it needs changes to genext2fs, mksquashfs etc. Mar 21 21:26:13 cshore: I meant to imply that keeping == 'do not mangle' Mar 21 21:26:17 xMff: cool...this is on my todo list but I don't know when I'll get to it Mar 21 21:26:51 ermo: that's what I mean...I don't think we care if the permissions are mangled as long as packages have a way to set the permissions we need Mar 21 21:26:51 i.e. presumably packages are set up correctly in the first place. And if they aren't, handling it with a find expression probably isn't the right way Mar 21 21:27:14 ermo: but then what out owner/group...that's something I want too Mar 21 21:27:22 cshore: I think that the permissions should be set correctly per package. Mar 21 21:27:41 ermo: agreed, permissions are per-package Mar 21 21:27:52 yeah but it should be an override Mar 21 21:27:59 i.e. in the case of sudo, it sets permissions in its Makefile. So why should I unconditionally clobber those afterwards? Mar 21 21:28:12 it is unrealistical to try to tag each and every file and directory in every package with permissions Mar 21 21:28:22 xMff: agreed Mar 21 21:28:35 xMff: I was thinking of having default permissions and overriding Mar 21 21:28:42 yes Mar 21 21:29:14 yeah, so 1) assume that packages set proper permissions and don't change them willy nilly 2) check that permissions are sane on packages (ongoing auditing process, more effort for widely used security critical applications) Mar 21 21:29:28 3) provide an override mechanism Mar 21 21:30:01 currently, 1) was fixed to the extent that ipk-build no longer strips permissions when creating .ipks (which are then later installed again) Mar 21 21:30:21 2) is not in the scope of this fix Mar 21 21:30:23 ermo: but is it even possible to no mangle the permissions with the mksquashfs stuff/ Mar 21 21:30:36 yes, mksquashfs does not mangle perms by default Mar 21 21:30:43 at least mksquashfs4 doesn't Mar 21 21:30:50 we only mangle uids and gids Mar 21 21:31:00 or it (mksquashfs) rather Mar 21 21:31:01 xMff: ah ok Mar 21 21:31:12 oh, ownership Mar 21 21:31:58 ermo: uhm, so what exactly are you trying to accomplish now (i.e. if we're not mangling perms, then what's the problem as far as perms go?) Mar 21 21:31:58 xMff: is everything set to 'root:root' or 'nobody:nobody' atm? Mar 21 21:31:59 and the best solution would be to patch mksquashfs and genext2fs etc. to read .tar files directly Mar 21 21:32:23 since .tar files can correctly describe ownerships and permissions Mar 21 21:32:32 xMff: I like that idea Mar 21 21:32:39 cshore: prior to my patch, we were mangling perms several places (that was part of my patch) Mar 21 21:32:50 perms *in several places Mar 21 21:33:14 xMff: I was wondering how to communicate the user/group to the mksquash and friends Mar 21 21:33:34 ermo: but that's fixed now, or are there still things that need fixed? Mar 21 21:33:51 for tar.gz images, it should be fixed. Mar 21 21:34:27 for squashfs/jffs, we're discussing improvements to the normalization (or whether the normalization is the right approach) Mar 21 21:34:30 ermo: are any perms (not uid/gid) currently being mangled Mar 21 21:34:37 cshore: hm, mksquashfs already supports a "pseudo file definition" Mar 21 21:35:01 cshore: it is a simple text format describing device nodes, one entry per line Mar 21 21:35:08 cshore: yes, for squashfs/jffs we normalize stuff to be world-readable Mar 21 21:35:12 cshore: like nod /dev/console 660 0 0 c 5 1 Mar 21 21:35:19 ermo: ah, ok Mar 21 21:35:35 cshore: and in some cases, world-readable != good Mar 21 21:35:37 cshore: it apparently also allows specifying directories, maybe it can be extended to cover files Mar 21 21:35:48 genext2fs has such an option too Mar 21 21:36:10 xMff: is it the same format, or would we have to output two different formats? Mar 21 21:36:28 "Pseudo-files allow fake directories, character devices, and block devices to be added to the Squashfs filesystem being built without requiring them to be present in the source filesystem. This allows a non-root user to create a squashfs filesystem containing device nodes and directories (but files)with arbitrary ownership/permissions." Mar 21 21:36:56 (but *not files)? Mar 21 21:37:25 yeah Mar 21 21:37:33 ermo: ah, ok, I think the normalization is wrong myself...only specific things we know need overriding should be overridden imo Mar 21 21:37:33 in any case the infrastructure is there Mar 21 21:39:07 xMff: ok, that's good to know...probably not until at least May for though (although I may have some free time in April depending on the employment situation). Mar 21 21:39:09 cshore: of course the format varies Mar 21 21:39:40 but its always the same one-record-per-line, columns-spearated-by-space kind of file Mar 21 21:39:53 xMff: ok, that's not too bad Mar 21 21:39:59 xMff: how about chmod a+X,u+r,go-w Mar 21 21:40:16 ermo: no Mar 21 21:40:25 ermo: go-w looks just wrong Mar 21 21:40:42 perhaps just a+X,u+r? Mar 21 21:41:09 perhaps Mar 21 21:41:31 ermo: why are you normalizing? Mar 21 21:42:01 cshore: he doesn't, he just tried to make buildroot preserve suid and other special bits Mar 21 21:42:15 cshore: I asked xMff the same thing -- it's something that has been done since the dawn of time by buildroot it seems Mar 21 21:42:26 cshore: buildroot normalizes for historical reasons Mar 21 21:42:39 xMff: ok, can we drop the normalization? Mar 21 21:42:47 that I do not know Mar 21 21:42:53 cshore: not without an audit, I should think? Mar 21 21:42:55 we probably can since a sane umask is ensured Mar 21 21:43:11 which has not always been the case Mar 21 21:43:15 I mean, dropping it *might* introduce undesireable side-effects Mar 21 21:43:50 but yes, the point is probably that normalization is better handled by umask Mar 21 21:43:57 cshore: I will concede as much :) Mar 21 21:44:12 ermo: I suspect an audit of even all of trunk would mean nothing happened Mar 21 21:44:52 ermo: never mind packages Mar 21 21:45:26 cshore: as in, you think that the normalization is superflous by now (because a consistent umask is used already at this point)? Mar 21 21:45:54 ermo: as in building and looking at the perms on every package in trunk would take insane amounts of time Mar 21 21:46:05 cshore: actually not Mar 21 21:46:11 there is buildroot Mar 21 21:46:14 erm buildbot Mar 21 21:46:33 you just grab the whole repo, unpack all *.ipk archives and do a big recursive ls -lR Mar 21 21:46:47 xMff: good point.... Mar 21 21:46:50 then you do the same once the normalization has been dropped and do a diff -u Mar 21 21:46:55 I did it before Mar 21 21:47:17 ok, my goal is to not set non-world-readable files world readable and to preserve SUID/SGID/Sticky bits Mar 21 21:47:49 cshore: and for getting the process started it is enough to verify that the base does not break Mar 21 21:47:50 Presently, I've tried to do the latter with the existing framework with minimal changes to the existing behaviour Mar 21 21:48:01 xMff: ok Mar 21 21:48:04 cshore: to avoid complete bricks are issues like non starting dnsmasq Mar 21 21:48:05 the former is trickier Mar 21 21:48:14 s/are/and/ Mar 21 21:48:45 once that has been done, one could start looking at the packagesd Mar 21 21:48:48 the present state is that non-world-readable files are normalized, which is bad. Mar 21 21:50:11 ermo: well if you can figure out something that works, great, but I think the best way to go is the final solution. Mar 21 21:50:53 or rather the permission part of the the final solution Mar 21 21:51:50 - $(FIND) $(TARGET_DIR) ! -perm /6000 -o ! -perm -o ! -name 'ssh_host*' -print0 | $(XARGS) -0 chmod a+rX,u+w,go-w Mar 21 21:52:34 what does ! -perm with no argument do? Mar 21 21:53:02 match and normalize files that do not have their SUID/SGID/sticky bits set OR are world readable OR or not named 'ssh_host*' Mar 21 21:53:29 ! = -not (but '!' is POSIX compliant, while '-not' isn't) Mar 21 21:53:48 yes but -perm without parameters mean world readable? Mar 21 21:53:55 oh, that was a mistake Mar 21 21:54:01 * ermo rechecks Mar 21 21:54:16 - $(FIND) $(TARGET_DIR) ! -perm /6000 -o ! -perm -/0004 ! -name 'ssh_host*' -print0 | $(XARGS) -0 chmod a+rX,u+w,go-w Mar 21 21:54:24 - $(FIND) $(TARGET_DIR) ! -perm /6000 -o ! -perm /0004 ! -name 'ssh_host*' -print0 | $(XARGS) -0 chmod a+rX,u+w,go-w Mar 21 21:54:46 go-w = XX55 Mar 21 21:54:59 or XX44 Mar 21 21:55:11 so not too different from the original 0755 Mar 21 21:55:16 and 0644 Mar 21 21:55:51 xMff: how do you like them apples? Mar 21 21:56:13 hm? Mar 21 21:56:20 dang, missed an -o Mar 21 21:56:46 using the expression - $(FIND) $(TARGET_DIR) ! -perm /6000 -o ! -perm -/0004 -o ! -name 'ssh_host*' -print0 | $(XARGS) -0 chmod a+rX,u+w,go-w Mar 21 21:56:58 xMff: I think that ^^ is better Mar 21 21:57:02 hm Mar 21 21:57:07 I need to test it later Mar 21 21:57:19 I'll capture it in #7667 Mar 21 21:58:20 * cshore needs to not need sleep Mar 21 21:59:55 I'll hit the bed. bbl Mar 21 22:00:06 night Mar 21 23:05:18 nbd * r26260 /trunk/include/ (download.mk package.mk): add support for md5sum checks for mirrored tarballs of packages with version control source urls Mar 21 23:05:26 nbd * r26261 /trunk/package/hostapd/ (17 files in 2 dirs): hostapd: update to 2011-02-21, use PKG_MIRROR_MD5SUM, includes fixes for WPS Mar 21 23:34:01 Does anyone here know why the language/python package for HOST is configured without threads? Mar 21 23:37:23 is there anything that needs threads for cross-building python stuff? Mar 22 00:01:33 nbd: I know the python library on FreeSWITCH git complains that the python doesn't support threads and refuses to proceed. Mar 22 00:01:57 hm, interesting Mar 22 00:02:01 maybe that should be changed then Mar 22 00:04:04 mazilo: have you got freeswitch in packages compiling - it seems to be broken right now Mar 22 00:04:07 ? Mar 22 00:04:37 cshore: I haven't got a chance to try the freeswitch 1.0.7, yet. Mar 22 00:05:21 isn't the current package 1.0.6? Mar 22 00:06:27 You should consider becoming maintainer for openwrt's freeswitch - it's currently orphaned Mar 22 00:07:20 cshore: Yes and IIRC the freeswitch 1.0.6 is compilable. It is the freeswitch 1.0.7 that I was thinking to try to compile. Currently, I am trying to get the python library o freeswitch git to compile, but it complains the OpenWRT python doesn't support threads. I took a look at the language/python/makefile and sure the configure calls for --without-threads switch. Mar 22 00:08:04 mazilo: something broke the fs compilation since you tested I think Mar 22 00:08:15 mazilo for 1.0.6 I mean Mar 22 00:08:29 I'm told people have issues Mar 22 00:09:27 cshore: I may have reported here the fs 1.0.6 breaks the compilation during the time when OpenWRT was upgrading the libtool. Mar 22 00:10:07 mazilo: ah, ok Mar 22 00:11:42 cshore: IIRC, the issue users encounter with FS is it crashes when trying to process Google Voice call using mod_dingaling. I believe this problem has something to do with something like "hardware allignment fault" (Half) on a Marvell Kirkwood platform. Mar 22 00:12:57 mazilo: hmmm....well I thought I'd let you know because I thought you might be interested since you're playing with it. Mar 22 00:14:09 cshore: IC. Hopefully, I will get sometimes tomorrow and will try to recompile fs 1.0.6. I will report back. Mar 22 00:14:35 mazilo: are you interested in maintainership? Mar 22 00:16:53 cshore: I sure will, but I am affraid that my knowledge is pretty limited to qualify as a maintainership. Mar 22 00:17:25 mazilo: You've done pretty well so far with FS afaict Mar 22 00:17:38 mazilo: and that's a hard package Mar 22 00:18:32 cshore: Honestly, I just did the copying from fs 1.0.6 and with some helps form xMff, nbd, and you. Mar 22 00:19:22 mazilo: that works for me, if works for the other devs...it still saves us work that wouldn't otherwise happen Mar 22 00:20:21 cshore: For the past four months, I have learnt more about how to build OpenWRT from reading the OpenWRT wiki. Mar 22 00:21:43 mazilo: that's cool...you've put in more effort than many, and you're still here Mar 22 00:22:07 cshore: Honestly, I am still amazed when I look at how you all created patches for OpenWRT packages. I am partocularly very impressed with xMff skills to come up with all sort of solution to fix the broken packages! Mar 22 00:22:50 mazilo: it comes with experience....I started from where you're at Mar 22 00:24:01 cshoere: Agree. I used to maintain several checkouts to build OpenWRT firmware for FON2100, NetGear WGT634U, etc. before I started reading the wiki on "Using Build Environment". Mar 22 00:25:35 mazilo: as long you don't commit broken stuff you're doing well Mar 22 00:26:11 and all of the devs have made mistakes in the past with a fix that was supposed to be easy Mar 22 00:26:15 cshore: BTW, I tried to replace '--without-threads' with '--with-threads="$(STAGING_DIR_HOST)/lib" for language/python/Makefile. Recompiled the python. Then, when I recompiled fs git, it still complains with "Your python lacks threads support, can not build mod_python". Mar 22 00:26:47 cshore: LOL. Mar 22 00:27:01 SHould it bit $(STAGING_DIR_HOST)/usr (i.e. does it add the lib part ? ... some packages do) Mar 22 00:27:10 *bit=be Mar 22 00:28:04 cshore: I took a at the staging_dir/host and it has "lib" (no "usr" directory.. Mar 22 00:29:08 mazilo: where is the thread library....maybe $(STAGING_DIR_HOST) then (no /lib) ? Mar 22 00:29:32 cshore: I am giving that a try right now. Mar 22 00:30:22 mazilo: for the host compile doesn't it use the thread library on the host system (i.e. not in $(STAGING_DIR) at all? Mar 22 00:30:31 so /usr/lib or /lib ? Mar 22 00:30:51 cshore: Honesly, I have no idea. :( Mar 22 00:31:13 cshore: I thought it should reflect to staging_dir/host. Mar 22 00:31:23 mazilo: I am almost positive that OpenWRT doesn't compile a host thread libs Mar 22 00:31:39 mazilo: so you you'd want /usr/lib most likely Mar 22 00:31:43 sorry /lib Mar 22 00:32:12 cshore: If I don't use staging_dir/host, it probably will use the /usr/lib from host. Mar 22 00:32:28 mazilo: try that Mar 22 00:33:12 host python is a tool running on the host system, not like toolchain gcc stuff IIRC Mar 22 00:33:15 cshore: Previously, before I messed up with using staging_dir/host, the mod_python seemed to compile OK. Mar 22 00:33:30 mazilo: lol Mar 22 00:33:54 mazilo: working harder than you need to Mar 22 00:34:03 cshore: Exactly. Mar 22 00:38:41 cshore * r26262 /packages/libs/zaptel-1.4.x/ (Makefile files/ files/10-create-device-node): [libs] zaptel-1.4.x: Added hotplug script to create correct Zaptel device nodes (hotplug's autocreate does the wrong thing). Mar 22 00:42:48 cshore * r26263 /packages/net/yate/Makefile: [net] Telephony: Yate: Added packages for files under /usr/share/yate, and created a minimal package collection for easy install. Mar 22 00:45:05 nbd * r26264 /trunk/package/mac80211/patches/310-pending_work.patch: ath9k: add a patch from linux-wireless@ for reducing driver size Mar 22 00:50:49 cshore: Looks like the '--with-threads=$(STAGING_DIR_HOST)' doesn't work. Back to use the '/usr/lib' on host. Mar 22 01:44:47 swalker * r26265 /packages/net/tor-alpha/Makefile: [packages] tor-alpha: update to 0.2.2.23-alpha, add missing librt dependency, use secure urls Mar 22 01:45:10 swalker * r26266 /packages/utils/zile/Makefile: [packages] zile: update to 2.3.23 **** ENDING LOGGING AT Tue Mar 22 02:59:57 2011