Re: [129924] trunk/base/src/port1.0/porttrace.tcl
On Dec 23, 2014, at 4:48 PM, Mihai Moldovan wrote:
> There's no technical reason. normalize and resolve operate on the
> (shared) original path. I don't really get your question, though. What
> would you have done differently?
Originally I was just thinking about reorganizing the code, but after
staring at it a bit, I'd suggest something like this. As far as I can tell,
using `realpath` here obviates both `file normalize` and `file
readlink`.
Can we just do this instead? It's simpler and more correct. Or are there
catches I'm not seeing?
vq
diff --git a/base/src/port1.0/porttrace.tcl b/base/src/port1.0/porttrace.tcl
index 7c9e1c1..3796a55 100644
--- a/base/src/port1.0/porttrace.tcl
+++ b/base/src/port1.0/porttrace.tcl
@@ -67,28 +67,11 @@ namespace eval porttrace {
# Escape equal signs with \=
lappend mapping "=" "\\="
-set normalizedPath [file normalize $path]
-# file normalize will leave symlinks as the very last
-# path component intact. This will, for instance, prevent /tmp from
-# being resolved to /private/tmp.
-# Also use file readlink to counter this behavior.
-# file readlink returns an error, if the last component is not
-# a symlink. Catch that.
-set resolvedPath {}
-if {![catch {file readlink $path}]} {
- set resolvedPath [file readlink $path]
-
- if {[string length $resolvedPath] > 0 && [string index $resolvedPath
0] ne "/"} {
- # Canonicalize.
- set resolvedPath [file normalize [file dirname
$path]/$resolvedPath]
- }
-}
lappend sndbxlst "[string map $mapping $path]=$action"
-if {$normalizedPath ne $path} {
-lappend sndbxlst "[string map $mapping $normalizedPath]=$action"
-}
-if {[string length $resolvedPath] > 0 && $resolvedPath ne $path} {
-lappend sndbxlst "[string map $mapping $resolvedPath]=$action"
+
+if {![catch {realpath $path} canonicalPath]
+&& $canonicalPath ne $path} {
+lappend sndbxlst "[string map $mapping $canonicalPath]=$action"
}
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libpgf Portfile
On Dec 24, 2014, at 5:45 PM, René J.V. Bertin wrote: > > I'm wondering about the port, though. I saw that libpgf appears to be part of > something called pgf which isn't the same thing already present as port:pgf . > I hope there's no unwritten rule that states I should propose a port for the > full monty, with libpgf a subport? I would just worry about the part that you need now. If the other parts are needed later we can deal with it then. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libpgf Portfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 25.12.2014 12:45 AM, René J.V. Bertin wrote: > Yess, that was it. It's possible that I hadn't yet added a version number > when I portindexed it, and never repeated the operation because that doesn't appear to be necessary for version bumps. Actually, it is. Without running portindex first, the port will not be recognized as outdated. > I'm wondering about the port, though. I saw that libpgf appears to be part of > something called pgf which isn't the same thing already present as port:pgf . I hope there's no unwritten rule that states I should propose a port for the full monty, with libpgf a subport? If it makes sense, they are related and (optionally) parts of the Portfile can be re-used, I'd suggest to do so. It's not really done consistently, though, so not much to worry about. Mihai -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJUm1GCAAoJEB/WLtluJTqH0okQAMssFW22BbXeNjxlYFUKehZZ gqWBxK4sRAa3ZxWtufmy5WnqCrkra7sDMXFIFU0l3PLkOfGDwLP1W7y6UcgewrYN 3PAaBuAKemNrbBZtINtT6LW2b0nNBZJiz6eF7mIXYIDPN5f7gOAKkx9pesQoR4LC 8ThL45tgAB/GSEeIq2kXkQsjiX0vI9gDSCR1tWUYp+HPxVOCJA9B3Fq0wg4MwaHY VbqZXuMNeIMZy/ZBpsZ5t+Qb3YryK4TXyZcRnWSObPEi1TvWmPfSo6DXzYSN7iqH P70OJftmovQE4eB0/7xjuzRwLO2C+DFCo8QFo4PtzMv9tMPanKPNkwBjaWlbXK+A c3DeKf171MDUo1fkEQ3P87eeln+nRKlre4OM5tUq2AVvhOyqtLqEmFl7wf2sqQ8d CPtGZVjD/v16hjGQRKr/iutiwm6fbcfaw8xp3pQ440Ks7UBeEgkbduDs5Z1LZfHX O+9PF9hjLfj+JsvAsIAW0+v0MTMtPuSUGC+9vDsL4eC4/aR4jeQjFX9HP6mrr9h0 5Ak13YAKOS5/rw5dzkvY6ySC8h/AoIw/xK/Rz1pbLIg1bTZLcJ9LpnbDp/ThZeOm 0ePH2GbctdbYX1moI9+UVioUo3Y8uz9fMI4+eWV/t0Xh8PRN274XJate6+6g5iNZ +sDpi2NHOWI9OGZEbFJ7 =Gegp -END PGP SIGNATURE- ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libpgf Portfile
On Wednesday December 24 2014 15:07:40 Ryan Schmidt wrote: Hi, > Any port install will first try to upgrade dependencies. Yeah, that's what I also realised thinking about it some more (and then saw it confirmed when `-n` had the intended effect). > > Off the top of my head I don't see a problem with the way the version is > declared in your preliminary libpgf Portfile, but perhaps there was the last > time you ran portindex on it? Perhaps rerunning portindex would get the > correct information into your index? Yess, that was it. It's possible that I hadn't yet added a version number when I portindexed it, and never repeated the operation because that doesn't appear to be necessary for version bumps. I'm wondering about the port, though. I saw that libpgf appears to be part of something called pgf which isn't the same thing already present as port:pgf . I hope there's no unwritten rule that states I should propose a port for the full monty, with libpgf a subport? R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libpgf Portfile
On Dec 24, 2014, at 4:57 AM, René J.V. Bertin wrote: > On Wednesday December 24 2014 01:39:23 René J.V. Bertin wrote: >> >> Attached is a draft for a port:libpgf portfile, basically following Gilles >> Gaulier's instructions at >> https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/master/entry/README.MACOSX#L62 >> . >> It's a prerequisite for digikam versions beyond 4.4.0 . >> >> Constructive critiques welcome to get this to submission quality. > > Apparently something's wrong that causes the message below when I do a > depends_lib-append port:libpgf : > > Error: Invalid port entry for libpgf, missing version > Error: Unable to execute port: upgrade libpgf failed > > > The log isn't any more explicit. Where does this message come from, and why > does a `port install digikam` try to do an upgrade of port:libpgf?! Any port install will first try to upgrade dependencies. Off the top of my head I don't see a problem with the way the version is declared in your preliminary libpgf Portfile, but perhaps there was the last time you ran portindex on it? Perhaps rerunning portindex would get the correct information into your index? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [129987] trunk/dports/devel/boost
Ryan Schmidt writes:
>> On Dec 23, 2014, at 6:42 PM, s...@macports.org wrote:
>>
>> Revision
>> 129987
>> Author
>> s...@macports.org
>> Date
>> 2014-12-23 16:42:44 -0800 (Tue, 23 Dec 2014)
>> Log Message
>>
>> boost: update to 1.57; closes #46156
>
>> Modified: trunk/dports/devel/boost/Portfile (129986 => 129987)
>> -# Although bjam can supposedly use parallel builds, it has random failures.
>> See #28878 and #23531.
>> -# To re-enable it, comment out the below and add '-j${build.jobs}' to
>> 'build.args', also below.
>> -#
>> -use_parallel_build no
>> +# Ever since the tickets #28878 and #23531 disabled parallel builds, boost
>> has
>> +# had many releases. We enable parallel builds back but can disable again if
>> +# problems arise.
>> +# use_parallel_build no
>
> You didn't add "-j${build.jobs}" to build.args, so it's still not doing a
> parallel build.
Oops, I missed that. Thanks.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libpgf Portfile
On Wednesday December 24 2014 01:39:23 René J.V. Bertin wrote: > Hello, > > Attached is a draft for a port:libpgf portfile, basically following Gilles > Gaulier's instructions at > https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/master/entry/README.MACOSX#L62 > . > It's a prerequisite for digikam versions beyond 4.4.0 . > > Constructive critiques welcome to get this to submission quality. Apparently something's wrong that causes the message below when I do a depends_lib-append port:libpgf : Error: Invalid port entry for libpgf, missing version Error: Unable to execute port: upgrade libpgf failed The log isn't any more explicit. Where does this message come from, and why does a `port install digikam` try to do an upgrade of port:libpgf?! R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: setuuid/setguuid
On Wednesday December 24 2014 21:47:11 Ian Wadham wrote: > > Without having really looked at the code, have you tried NOT doing that > > (possibly after checking whether it has the required privileges)? > > I did, but the KDE ReviewBoard jockeys pooh-poohed that. In the end I > modified Well, yeah, *they* don't have to put up with OS X quirks. > KCrash not to attempt to use kdeinit4 to start Dr K in Apple OS X. > > I really am very weary of that whole business and I especially do not wish to > discuss it on Christmas Day, which is just over 2 hours away ATM in Australia. I understand. So just answer this when you feel like it: what happened when you did the pooh-poohed thing, did it work? R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: setuuid/setguuid
On 24/12/2014, at 9:27 PM, René J.V. Bertin wrote: > On Wednesday December 24 2014 21:16:54 Ian Wadham wrote: >> The code always seems to work OK if the crash procedure in the failed >> program starts Dr Konqi by forking. But it never works (on Apple OS X) >> if the crash procedure contacts an independent process (kdeinit4) via >> a socket and asks kdeinit4 to run Dr Konqi. Starting via kdeinit4 is >> preferred to forking, in case the crashed program has a corrupted >> heap or whatever. > > And all that DrKonqi really does is starting and stopping the crashed process > via signals, and spawning a debugger with the necessary arguments for it to > connect to the target process. > >> i.e. the crashing program, Dr Konqi and kdeinit4. That's the silly thing >> about this situation. OS X won't let Dr K set privileges it already has. > > Without having really looked at the code, have you tried NOT doing that > (possibly after checking whether it has the required privileges)? I did, but the KDE ReviewBoard jockeys pooh-poohed that. In the end I modified KCrash not to attempt to use kdeinit4 to start Dr K in Apple OS X. I really am very weary of that whole business and I especially do not wish to discuss it on Christmas Day, which is just over 2 hours away ATM in Australia. Merry Christmas, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: setuuid/setguuid
On Wednesday December 24 2014 21:16:54 Ian Wadham wrote: Morning! > The code always seems to work OK if the crash procedure in the failed > program starts Dr Konqi by forking. But it never works (on Apple OS X) > if the crash procedure contacts an independent process (kdeinit4) via > a socket and asks kdeinit4 to run Dr Konqi. Starting via kdeinit4 is > preferred to forking, in case the crashed program has a corrupted > heap or whatever. And all that DrKonqi really does is starting and stopping the crashed process via signals, and spawning a debugger with the necessary arguments for it to connect to the target process. > i.e. the crashing program, Dr Konqi and kdeinit4. That's the silly thing > about this situation. OS X won't let Dr K set privileges it already has. Without having really looked at the code, have you tried NOT doing that (possibly after checking whether it has the required privileges)? R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: setuuid/setguuid
On 24/12/2014, at 8:52 AM, Joshua Root wrote:
> On 2014-12-24 08:15 , Ian Wadham wrote:
>> Hi Clemens,
>>
>> On 23/12/2014, at 11:33 PM, Clemens Lang wrote:
>>> - On 23 Dec, 2014, at 13:02, René J.V. Bertin rjvber...@gmail.com wrote:
IIRC, OS X no longer allows setuuid/setguuid, or only under some
conditions.
Isn't that something that ought to be addressed in the post-destroot?
I'd vote for removing the offending flags if they cannot have their
intended
effect anyway.
>>>
>>> That's the first time I hear of that. Unless you have a source you can
>>> quote on
>>> that I'm not going to believe you, especially since my SUID (not setuuid,
>>> that's
>>> not a thing) binaries still work as I expect them to.
>>
>> Is this topic anything to do with the following Apple OS X message?
>> "The application with bundle ID (null) is running setugid(), which is not
>> allowed."
>> Google on "Apple setugid". That message has been giving people trouble for
>> a couple of years at least. "setugid()" is Apple's shorthand for (regexp)
>> "set[ug]id()".
>>
>> I used to get the message from Dr Konqi (KDE's crash analyser), till I
>> bypassed
>> the offending code by stopping KCrash from trying to run Dr Konqi via
>> kdeinit4.
>>
>> The source for main.cpp of Dr Konqi currently reads:
>>
>> -
>> int main(int argc, char* argv[])
>> {
>> #ifndef Q_OS_WIN //krazy:exclude=cpp
>> // TODO - Investigate and fix this, or work around it as follows...
>> // #if !defined(Q_OS_WIN) && !defined(Q_OS_MAC)
>> // When starting Dr Konqi via kdeinit4, Apple OS X aborts us unconditionally
>> for
>> // using setgid/setuid, even if the privs were those of the logged-in user.
>> // Drop privs.
>>setgid(getgid());
>>if (setuid(getuid()) < 0 && geteuid() != getuid()) {
>>exit(255);
>>}
>> #endif
>> -
>>
>> The notes are to remind me to investigate this problem further if I ever get
>> kdeinit4 (or kdeinit5) to work properly on Apple OS X and MacPorts.
>
> Does this code run as root?
Normally no.
> If not, setgid and setuid will not work. You
> might try wrapping the whole thing in a getuid() == 0 check.
Thanks for the suggestion, Joshua.
> Also, the "setgid(getgid());" seems a bit suspect. I can only assume
> it's there to reset the egid by side effect? An explicit setegid would
> be a lot more clear in that case.
The Dr Konqi code is a crash analyser and is supposed to run without
special privileges, even if the program that crashed had such privileges.
I think the code is trying to ensure or restore normal user privileges.
The code always seems to work OK if the crash procedure in the failed
program starts Dr Konqi by forking. But it never works (on Apple OS X)
if the crash procedure contacts an independent process (kdeinit4) via
a socket and asks kdeinit4 to run Dr Konqi. Starting via kdeinit4 is
preferred to forking, in case the crashed program has a corrupted
heap or whatever.
All my testing has been with programs that had normal user privileges,
i.e. the crashing program, Dr Konqi and kdeinit4. That's the silly thing
about this situation. OS X won't let Dr K set privileges it already has.
I am not working on this ATM. I just brought it up as an example (for
Clemens) of OS X not allowing setuid/setgid.
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Request to help review Julien's contributions
Hi, To keep the highly productive contributors stay motivated, I would like to ask other committers to help reviewing Julien's patches: http://trac.macports.org/query?status=!closed&reporter=jul_bsd%40yahoo.fr >From what I've seen so far these are high quality patches, but he had to add a lot of small dependencies to make other bigger packages work, so there's a lot of work to do. (If someone points out a minor issue, he usually updates all other tickets in the same spirit very fast.) While we cannot influence decisions about commit rights, reviewing and accepting the patches is the least we can do for non-committers. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
