On Aug 16, 2015 2:59 PM, "Reindl Harald" wrote:
>
>
> Am 16.08.2015 um 20:52 schrieb Eric Griffith:
>>
>> > *No one else* suggested discarding /sbin. Doing so
>> > will break decades of stable open source and free software.
>>
>> Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?
>
>
>
On Sun, Aug 16, 2015 at 7:25 PM, Reindl Harald
wrote:
>
> Am 17.08.2015 um 01:22 schrieb Nico Kadel-Garcia:
>
>> On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia
>> wrote:
>>
>>> On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald
>>> wrote:
>>>
Am 16.08.2015 um 18:57 schrieb Nico Kadel-
Am 17.08.2015 um 01:22 schrieb Nico Kadel-Garcia:
On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia wrote:
On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald wrote:
Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:
It's a basic violation of the ordinary segregation between "/bin" as
ordinar
Am 17.08.2015 um 00:24 schrieb Nico Kadel-Garcia:
On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald wrote:
Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:
It's a basic violation of the ordinary segregation between "/bin" as
ordinary user tools" and "/sbin" as sysadmin tools to start mixing
On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia wrote:
> On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald wrote:
>>
>> Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:
>>>
>>> It's a basic violation of the ordinary segregation between "/bin" as
>>> ordinary user tools" and "/sbin" as sysadmin t
On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald wrote:
>
> Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:
>>
>> It's a basic violation of the ordinary segregation between "/bin" as
>> ordinary user tools" and "/sbin" as sysadmin tools to start mixing
>> them, and much more confusing to have the
On Sun, Aug 16, 2015 at 06:35:28PM +0200, drago01 wrote:
> > Yeah, that's why I was suggesting using it instead for things that
> > really have no business being in anyone's path, root or not, rather
> > than have it relate to privileges at all. But, again, only
> > halfheartedly.
> That's what lib
Am 16.08.2015 um 20:52 schrieb Eric Griffith:
> *No one else* suggested discarding /sbin. Doing so
> will break decades of stable open source and free software.
Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?
maybe
but even if not, it don't matter and would not break *anything
On Sun, Aug 16, 2015 at 2:52 PM, Eric Griffith
wrote:
>
> Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?
>
Looks like they did.
[gsgatlin@arch64 ~]$ ls -al /usr/sbin
lrwxrwxrwx 1 root root 3 Feb 15 16:57 /usr/sbin -> bin
--
devel mailing list
devel@lists.fedoraproject.org
https:/
> *No one else* suggested discarding /sbin. Doing so
> will break decades of stable open source and free software.
Didn't Arch move /usr/sbin to just be a symlink to /usr/bin?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:
It's a basic violation of the ordinary segregation between "/bin" as
ordinary user tools" and "/sbin" as sysadmin tools to start mixing
them, and much more confusing to have the same program name in both.
And it's frankly easy to avoid. "mock", f
On Sun, 16.08.15 12:57, Nico Kadel-Garcia (nka...@gmail.com) wrote:
> > In general: encoding privilige policy into the API through binary
> > paths is a really bad idea, as policy shouldn't be considered strict
> > API (or to be more precise: it should be allowed to open up policy --
> > while of
On Sun, Aug 16, 2015 at 8:03 AM, Lennart Poettering
wrote:
> On Fri, 14.08.15 17:58, Matthew Miller (mat...@fedoraproject.org) wrote:
>
>> On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
>> > Given that sbin is in $PATH for unprivileged users too the seperation
>> > is really p
On Sun, Aug 16, 2015 at 6:32 PM, Matthew Miller
wrote:
> On Sun, Aug 16, 2015 at 02:03:38PM +0200, Lennart Poettering wrote:
>> In general: encoding privilige policy into the API through binary
>> paths is a really bad idea, as policy shouldn't be considered strict
>> API (or to be more precise: i
On Sun, Aug 16, 2015 at 02:03:38PM +0200, Lennart Poettering wrote:
> In general: encoding privilige policy into the API through binary
> paths is a really bad idea, as policy shouldn't be considered strict
> API (or to be more precise: it should be allowed to open up policy --
> while of course no
On Fri, 14.08.15 17:58, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
> > Given that sbin is in $PATH for unprivileged users too the seperation
> > is really pointless, since it's now only the $PATH order which makes
> > this
On Sat, Aug 15, 2015 at 12:23:50PM -0400, Nico Kadel-Garcia wrote:
>
> "mock" has a similar problem. That one is simply foolish: The
> /usr/bin/mock command *isn't* mock. It's a helper program to summon
> the /usr/sbin/mock, which is the "real" mock. Hilarity ensues if you
> have PATH set up as ma
On Mon, Aug 10, 2015 at 2:19 PM, Kevin Fenzi wrote:
> On Mon, 10 Aug 2015 12:12:17 -0600
> Orion Poplawski wrote:
>
>> iproute has /usr/sbin/ss
>> stripesnoop has /usr/bin/ss
>>
>> This causes problems:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1249328
>>
>> It seems like we should have a po
On Fri, Aug 14, 2015 at 02:17:04PM -0700, Josh Stone wrote:
> Well, mock is just using consolehelper, so I guess you should set your
> sights on that. Another big example with consolehelper is authconfig.
Yeah probably good fix all of those things. I see there isn't much
left.
--
Matthew Miller
On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
> Given that sbin is in $PATH for unprivileged users too the seperation
> is really pointless, since it's now only the $PATH order which makes
> this not explode.
Yeah; I have a halfhearted wish to rationalize what goes in sbin an
On 08/14/2015 10:24 AM, Lennart Poettering wrote:
> On Mon, 10.08.15 11:50, Josh Stone (jist...@redhat.com) wrote:
>
>> On 08/10/2015 11:12 AM, Orion Poplawski wrote:
>>> iproute has /usr/sbin/ss
>>> stripesnoop has /usr/bin/ss
>>>
>>> This causes problems: https://bugzilla.redhat.com/show_bug.cgi
On Mon, 10.08.15 11:50, Josh Stone (jist...@redhat.com) wrote:
> On 08/10/2015 11:12 AM, Orion Poplawski wrote:
> > iproute has /usr/sbin/ss
> > stripesnoop has /usr/bin/ss
> >
> > This causes problems: https://bugzilla.redhat.com/show_bug.cgi?id=1249328
> >
> > It seems like we should have a po
On Mon, 10 Aug, 2015 at 18:50:52 GMT, Josh Stone wrote:
> Do emphasize *different* programs or packages, as there are legitimate
> self-contained cases -- /usr/bin/mock vs. /usr/sbin/mock for instance.
Anyone who wants to chime in on this, there is already a bug:
https://bugzilla.redhat.com/s
On Mon, Aug 10, 2015 at 12:19:39PM -0600, Kevin Fenzi wrote:
> On Mon, 10 Aug 2015 12:12:17 -0600
> Orion Poplawski wrote:
>
> > iproute has /usr/sbin/ss
> > stripesnoop has /usr/bin/ss
> >
> > This causes problems:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1249328
> >
> > It seems like w
On 08/10/2015 11:54 AM, Reindl Harald wrote:
>
> Am 10.08.2015 um 20:50 schrieb Josh Stone:
>> On 08/10/2015 11:12 AM, Orion Poplawski wrote:
>>> iproute has /usr/sbin/ss
>>> stripesnoop has /usr/bin/ss
>>>
>>> This causes problems: https://bugzilla.redhat.com/show_bug.cgi?id=1249328
>>>
>>> It se
Am 10.08.2015 um 20:50 schrieb Josh Stone:
On 08/10/2015 11:12 AM, Orion Poplawski wrote:
iproute has /usr/sbin/ss
stripesnoop has /usr/bin/ss
This causes problems: https://bugzilla.redhat.com/show_bug.cgi?id=1249328
It seems like we should have a policy prohibiting different programs with th
On 08/10/2015 11:12 AM, Orion Poplawski wrote:
> iproute has /usr/sbin/ss
> stripesnoop has /usr/bin/ss
>
> This causes problems: https://bugzilla.redhat.com/show_bug.cgi?id=1249328
>
> It seems like we should have a policy prohibiting different programs with the
> same command names being in /us
On Mon, 10 Aug 2015 12:12:17 -0600
Orion Poplawski wrote:
> iproute has /usr/sbin/ss
> stripesnoop has /usr/bin/ss
>
> This causes problems:
> https://bugzilla.redhat.com/show_bug.cgi?id=1249328
>
> It seems like we should have a policy prohibiting different programs
> with the same command nam
28 matches
Mail list logo
