[gentoo-dev] RFC: iotop needs to run as root after kernel change

[gentoo-dev] RFC: iotop needs to run as root after kernel change

[justin]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

Hi,

after this change

https://github.com/torvalds/linux/commit/1a51410abe7d0ee4b1d112780f46df87d3621043

iotop cannot be used as user anymore.
Any suggestions how to proceed?

The solution I see are

1.
Leave it to root (Fedora and Suses way)
2.
suid it (bad in my view)
3.
file capabilities (can this be done with portage)

Please comment and help me with the right proceeding.

justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On 4/4/12 8:32 AM, justin wrote:
> 1.
> Leave it to root (Fedora and Suses way)

I think that's the best option, at least for now.

> 2.
> suid it (bad in my view)

Agreed, that'd be very bad, any crashing bug in it could become a
privilege escalation problem.

> 3.
> file capabilities (can this be done with portage)

Slightly better than the above, but I still prefer #1.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[vivo75]

Il 04/04/2012 08:43, "Paweł Hajdan, Jr." ha scritto:
> On 4/4/12 8:32 AM, justin wrote:
>> 1.
>> Leave it to root (Fedora and Suses way)
> I think that's the best option, at least for now.
>
>> 2.
>> suid it (bad in my view)
> Agreed, that'd be very bad, any crashing bug in it could become a
> privilege escalation problem.
>
>> 3.
>> file capabilities (can this be done with portage)
> Slightly better than the above, but I still prefer #1.

Or default to 1. but provide a use flag to achieve 3.
net-wireless/kismet uses 'suid', maybe other use 'caps' use flags?
Hopefully others can answer on how to apply capabilities to executables

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[Chí-Thanh Christopher Nguyễn]

justin schrieb:
> iotop cannot be used as user anymore.
> Any suggestions how to proceed?
>
> Leave it to root (Fedora and Suses way)
> suid it (bad in my view)

I suggest to have a suid USE flag (disabled by default) so the user can
choose between the two. Maybe advertise this change in an elog message.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[Alec Warner]

2012/4/4 Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org>:
> justin schrieb:
>> iotop cannot be used as user anymore.
>> Any suggestions how to proceed?
>>
>> Leave it to root (Fedora and Suses way)
>> suid it (bad in my view)
>
> I suggest to have a suid USE flag (disabled by default) so the user can
> choose between the two. Maybe advertise this change in an elog message.

Doesn't FEATURES=suidctl already cover crap like this?

-A

>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Wed, 04 Apr 2012 08:32:41 +0200
justin <jlec@gentoo.org> wrote:
> 3.
> file capabilities (can this be done with portage)

It can't. We've had discussions about caps before, and I imagine it
would get into EAPI 5 without objections if you can come up with a spec
that describes how it should work (bear in mind that some of the target
filesystems might not support caps).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[Greg KH]

On Wed, Apr 04, 2012 at 08:32:41AM +0200, justin wrote:
> Hi,
> 
> after this change
> 
> https://github.com/torvalds/linux/commit/1a51410abe7d0ee4b1d112780f46df87d3621043
> 
> iotop cannot be used as user anymore.
> Any suggestions how to proceed?
> 
> The solution I see are
> 
> 1.
> Leave it to root (Fedora and Suses way)

Please leave it this way, the information leakage otherwise is too big
of a risk to do anything else.

greg k-h

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[justin]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On 04/04/12 14:56, Greg KH wrote:

> On Wed, Apr 04, 2012 at 08:32:41AM +0200, justin wrote:
>> Hi,
>>
>> after this change
>>
>> https://github.com/torvalds/linux/commit/1a51410abe7d0ee4b1d112780f46df87d3621043
>>
>> iotop cannot be used as user anymore.
>> Any suggestions how to proceed?
>>
>> The solution I see are
>>
>> 1.
>> Leave it to root (Fedora and Suses way)
> 
> Please leave it this way, the information leakage otherwise is too big
> of a risk to do anything else.
> 
> greg k-h
> 



Thanks for all your responses. I will follow what was suggested by
upstream and what is the best from my feelings and restrict it to be
root only.

justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[Mike Gilbert]

On Wed, Apr 4, 2012 at 2:32 AM, justin <jlec@gentoo.org> wrote:
> 2.
> suid it (bad in my view)
> 3.
> file capabilities (can this be done with portage)
>

iotop is a python script, so these were not really options anyway.
Unless you wrote a wrapper in C or something. :)

[gentoo-dev] Re: RFC: iotop needs to run as root after kernel change

[Duncan]

Ciaran McCreesh posted on Wed, 04 Apr 2012 11:50:54 +0100 as excerpted:

> On Wed, 04 Apr 2012 08:32:41 +0200 justin <jlec@gentoo.org> wrote:
>> 3.
>> file capabilities (can this be done with portage)
> 
> It can't. We've had discussions about caps before, and I imagine it
> would get into EAPI 5 without objections if you can come up with a spec
> that describes how it should work (bear in mind that some of the target
> filesystems might not support caps).

Isn't that what portage's xattr USE flag is all about, supporting caps, 
etc, via xattr?  Altho as you said, it does require support on both 
PORTAGE_TMPDIR and the live filesystem.  (I believe portage's install 
warns if the USE flag is on and either tmpfs or the live filesystem 
doesn't support it.)

But that's a fairly new feature, probably not in stable, yet, and for all 
I know, 2.2 only.  And while I guess a few packages support it via 
USE=caps, full and proper EAPI support couldn't be a bad thing.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman