FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-04-2012, 06:32 AM
justin
 
Default RFC: iotop needs to run as root after kernel change

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
 
Old 04-04-2012, 06:43 AM
"Paweł Hajdan, Jr."
 
Default RFC: iotop needs to run as root after kernel change

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.
 
Old 04-04-2012, 10:01 AM
"vivo75@gmail.com"
 
Default RFC: iotop needs to run as root after kernel change

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
 
Old 04-04-2012, 10:25 AM
Alec Warner
 
Default RFC: iotop needs to run as root after kernel change

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
>
>
 
Old 04-04-2012, 10:50 AM
Ciaran McCreesh
 
Default RFC: iotop needs to run as root after kernel change

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
 
Old 04-04-2012, 12:56 PM
Greg KH
 
Default RFC: iotop needs to run as root after kernel change

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
 
Old 04-04-2012, 01:22 PM
justin
 
Default RFC: iotop needs to run as root after kernel change

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
 
Old 04-04-2012, 01:47 PM
Mike Gilbert
 
Default RFC: iotop needs to run as root after kernel change

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.
 
Old 04-05-2012, 01:18 AM
Duncan
 
Default RFC: iotop needs to run as root after kernel change

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
 

Thread Tools




All times are GMT. The time now is 08:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org