Re: [gentoo-dev] Re: Are users forced to use PAM?
On Mon, 06 Oct 2014 03:53:11 +0300 Nikos Chantziaras wrote: >On 05/10/14 16:20, Diego Elio Pettenò wrote: >> Please get upstream to apply the patch and release a new sudo >> version. >> >> Simple as this: -pam is not by default tested and you keep the >> pieces if it breaks. If you can get upstream to just apply that >> patch, you solve your problem. Insulting developers as it's >> happening on that bug will bring you nowhere. > >I didn't insult anyone. > > > Yeah, we didn't mean you. Sorry if that impression might have arose. But as can be clearly seen in the bug, there is a person which thinks insults and rude behavior could speed up things. He could not be more wrong but that's a different topic and should not be discussed here. Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
[gentoo-dev] Re: Are users forced to use PAM?
On 05/10/14 16:20, Diego Elio Pettenò wrote: Please get upstream to apply the patch and release a new sudo version. Simple as this: -pam is not by default tested and you keep the pieces if it breaks. If you can get upstream to just apply that patch, you solve your problem. Insulting developers as it's happening on that bug will bring you nowhere. I didn't insult anyone.
Re: [gentoo-dev] Dropping GCC maintainership
On 10/05/2014 06:44 PM, Ryan Hill wrote: > Hey all, I'm stepping down as GCC maintainer. I haven't been reading > toolchain > bugmail since June, and keep telling myself I'll tackle it next weekend, which > never happens. To be frank, I'm kinda sick of Gentoo. I'm hoping it's > temporary but we'll see. In the meantime I don't want to be responsible for > holding up any work while I figure things out. > Thanks for your services, it's been great having you. I hope that you take a short break, and come back refreshed to have fun with gentoo after. -Zero signature.asc Description: OpenPGP digital signature
[gentoo-dev] Dropping GCC maintainership
Hey all, I'm stepping down as GCC maintainer. I haven't been reading toolchain bugmail since June, and keep telling myself I'll tackle it next weekend, which never happens. To be frank, I'm kinda sick of Gentoo. I'm hoping it's temporary but we'll see. In the meantime I don't want to be responsible for holding up any work while I figure things out. Thanks, -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Looking for alternative to RESTRICT=userpriv
On 10/02/2014 07:32 PM, Steven J. Long wrote: > On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote: >> On 09/29/2014 04:31 PM, Steven J. Long wrote: >>> On Mon, Sep 29, 2014, Zac Medico wrote: On 09/28/2014, Steven J. Long wrote: > On Wed, Sep 24, 2014, Zac Medico wrote: >> 1) When esudo is called, it saves the current (unprivileged) bash >> environment to a file. >> >> 2) esudo uses IPC to request that a process with elevated privileges be >> launched to run a specific command using the saved environment, and that >> the environment of the elevated process be saved to a file after the >> command completes. > > I don't think it's going to be quite that easy to get the output env, > certainly not from some random command; tbh I don't even see the need > for it, unless I'm missing something. From the "elevated process" after > it waits on the child, but not from the child unless you control the > code. We control the shell code that launches the requested command, so we can save the environment after the requested command completes (using a modified version of our existing environment persistence code). >>> >>> Yeah but think it through; the "elevated process" inherits its environment >>> from us (current state, as normal). It runs a child process: nothing in the >>> env of that child is going to affect our env, by definition. The command >>> completes, and we save back the same env we started with. >>> >>> Sure, the child inherits its env from us, but we don't need to do anything >>> to make that happen: it's standard. In fact we take efforts to clean the >>> env in some situations for that reason. >>> >>> I just can't see it working, apart from perhaps where a command outputs >>> settings which should be run through eval. In which case, eval them >>> in ebuild space after the command has output whatever under esudo. To >>> be flexible, you're going to want to save them anyway for later use, >>> which again implies that happening in the ebuild/eclass. >> >> You're thinking in terms of a SUID helper like sudo. The implementation >> that I've been suggesting does not involve a SUID helper. > > No, I'm thinking in terms of "a process with elevated privileges" running > "a specific command"; whether that first process is started by us or not, > is irrelevant to whether it can get the environment from a child process > we have no control over, after it "completes". You're assuming that we have no control over the child process, which would be true with a SUID helper like sudo (in the absence of a wrapper script, see below) that is only designed to run a specific command and then exit without saving the enviroment. However, imagine a helper that is designed to run a requested shell command and then save the environment before it exits. It could be done with sudo if you simply required that the first argument to sudo be a wrapper script that executes the requested command and then saves the environment. For example, consider the following usage: sudo /foo/bar/wrapper.sh If the sudo command is constructed shown above, then wrapper.sh can load an arbitrary environment, execute the requested shell command with arguments, and then save the resulting environment afterwards. > Sure it can save its own, but since it's a generic "run any command" helper, > it can't do much more than give us back what we gave it, unless you're > talking about echoing back settings, in the manner of gpg et al, which > by definition is not about the saved env. That's why we have to use that > format in the first place; because the env setting must be done by the > process which wants to use it (have it inherited for child processes), > for the same reason: a child process can never affect the parent env. We could implement esudo so that it will insert wrapper.sh into the sudo arguments, so that the caller doesn't have to know anything about the wrapper.sh implementation details. For example: esudo So, the privilege escalation mechanism is indeed irrelevant, as long as there's some opportunity to insert a wrapper script that runs with escalated privileges, allowing it to load/save the environment at the appropriate time during shell execution. >> Instead, IPC >> would be used to request that the privileged parent process launch a new >> privileged process on behalf of esudo. In this context, unless the esudo >> implementation provides explicit support for environment inheritance, >> the new privileged process will not inherit any environment from the >> environment where esudo was called. > > Well, assuming that were the implementation, that explains why you'd want > to save the env off, so that the privileged helper can access it. It still > sounds like more work in the long run in terms of what's happening, but > regardless: it doesn't get you the resultant env from the child command. Except that it is possible to save the resultant en
Re: [gentoo-dev] Are users forced to use PAM?
On Sun, 5 Oct 2014 14:20:49 +0100 Diego Elio Pettenò wrote: > Insulting developers as it's happening on that bug will bring you > nowhere. Sadly, the person in question has been on my watch list for a very long time. jer
Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml
On Sun, 5 Oct 2014 18:30:04 +0200 Tom Wijsman wrote: > On Sat, 4 Oct 2014 09:18:55 +0200 > Jeroen Roovers wrote: > > > f...@gentoo.org > > .. > to keep willikins' !meta -v functionality working. You mean we should design our organisational structures around an IRC bot now? jer
Re: [gentoo-dev] Adding dev-lang/perl version to emerge --info
On 00:27 Sat 04 Oct , Lars Wendler wrote: > On Sat, 4 Oct 2014 00:05:19 +0200 Andreas K. Huettel wrote: > > > ... > >since Perl is a fairly central package and it's hard to debug problems > >without the exact version, the perl team would like to add > >dev-lang/perl to profiles/info_pkgs. > > > >This has the effect that the installed version of dev-lang/perl is by > >default included in every "emerge --info" output. > > > >Opinions, encouragement, opposition, flamewars? :) > > > >Cheers, > >Andreas > > > > Doit! This has always bugged me and it could be quite helpful. > ++ -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpaI6WVHECfB.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml
On Sat, 4 Oct 2014 09:18:55 +0200 Jeroen Roovers wrote: > f...@gentoo.org .. to keep willikins' !meta -v functionality working.
Re: [gentoo-dev] Last rites: dev-php/{adodb-ext,eaccelerator,pecl-apc,pecl-id3,pecl-mogilefs,pecl-sca_sdo,suhosin}
Hi Brian, On 02.10.2014 20:29, Brian Evans wrote: > # Brian Evans ( 1 Oct 2014 ) # Masked for > removal in 30 days. # Broken on >=dev-lang/php-5.4. No > replacements known. [..] dev-php/suhosin is that true for suhosin? Upstream reads "has been tested with PHP 5.4 and 5.5" [1] and there is dev-php/suhosin: version bump - 0.9.36 is available and has been tested with PHP 5.4 and 5.5 https://bugs.gentoo.org/show_bug.cgi?id=520178 too. So at least to me this looks like to early or potentially not even needed. If it is broken fro 5.4/5.5 please share details on why it really is and update the bug mentioned above too, please. Thanks! Best, Sebastian [1] http://suhosin.org/stories/install.html
Re: [gentoo-dev] Are users forced to use PAM?
Thanks for looking it up Matthias. Sounds like me or someone else will get to it asap (not on my laptop right now to commit). On Oct 5, 2014 4:45 PM, "Matthias Maier" wrote: > > Am 05. Oct 2014, 15:20 schrieb Diego Elio Pettenò >: > > > Simple as this: -pam is not by default tested and you keep the pieces if > it > > breaks. > > Upstream bug is at [1]. According to comment 1 also upstream does not > seem to test non-pam use cases all that often. > > I have the impression that all this fuzz around bug 524074 could have > been handled in a much more civilized manner... > > "Are users forced to use PAM?" - we might want to inform upstream > (politely) that we still support non-pam use cases. Otherwise the > dependency might become mandatory. > > Best, > Matthias > > [1] http://www.sudo.ws/bugs/show_bug.cgi?id=667 > >
Re: [gentoo-dev] Are users forced to use PAM?
Am 05. Oct 2014, 15:20 schrieb Diego Elio Pettenò : > Simple as this: -pam is not by default tested and you keep the pieces if it > breaks. Upstream bug is at [1]. According to comment 1 also upstream does not seem to test non-pam use cases all that often. I have the impression that all this fuzz around bug 524074 could have been handled in a much more civilized manner... "Are users forced to use PAM?" - we might want to inform upstream (politely) that we still support non-pam use cases. Otherwise the dependency might become mandatory. Best, Matthias [1] http://www.sudo.ws/bugs/show_bug.cgi?id=667
Re: [gentoo-dev] Are users forced to use PAM?
Please get upstream to apply the patch and release a new sudo version. Simple as this: -pam is not by default tested and you keep the pieces if it breaks. If you can get upstream to just apply that patch, you solve your problem. Insulting developers as it's happening on that bug will bring you nowhere. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 5 October 2014 11:18, Nikos Chantziaras wrote: > In bug 524074 (https://bugs.gentoo.org/show_bug.cgi?id=524074), Joshua > Kinard mentioned that Gentoo cannot support systems where PAM isn't > installed. I'd like to know whether this is true or not, especially since > no part of the system seems to actually require it. It is there if you need > it. I don't have a use for it, personally. > > (The issue at hand is that sudo links against -lshadow, which should not > happen and therefore that link command removed from the build.) > > >
[gentoo-dev] Re: Are users forced to use PAM?
Nikos Chantziaras wrote: > In bug 524074 (https://bugs.gentoo.org/show_bug.cgi?id=524074), Joshua > Kinard mentioned that Gentoo cannot support systems where PAM isn't > installed. All my gentoo boxes run without pam from the very beginning (since many years). I hope that it will not be necessary to maintain ebuils in my overlay, should the USE=-pam option be removed from some packages. > (The issue at hand is that sudo links against -lshadow I suppose that this shouldn't be a hard fix, since previous sudo versions compiled well with USE=-pam, and there is no libshadow on my system (except for an xorg-module of that name, but I suppose that this is unrelated).
Re: [gentoo-dev] Are users forced to use PAM?
141005 Nikos Chantziaras wrote: > In bug 524074 (https://bugs.gentoo.org/show_bug.cgi?id=524074), > Joshua Kinard mentioned that Gentoo cannot support systems > where PAM isn't installed. I'd like to know whether this is true or not, > especially since no part of the system seems to actually require it. > The issue at hand is that sudo links against -lshadow, > which should not happen > and therefore that link command removed from the build. I don't have Pam installed nor Sudo. I start my USE flags with '-*' (yes, I know ... (smile)). -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-dev] Are users forced to use PAM?
In bug 524074 (https://bugs.gentoo.org/show_bug.cgi?id=524074), Joshua Kinard mentioned that Gentoo cannot support systems where PAM isn't installed. I'd like to know whether this is true or not, especially since no part of the system seems to actually require it. It is there if you need it. I don't have a use for it, personally. (The issue at hand is that sudo links against -lshadow, which should not happen and therefore that link command removed from the build.)
