[linux-lvm] Bug! lvs shouldn't need 'root' access

[linux-lvm] Bug! lvs shouldn't need 'root' access

[Linda A. Walsh]

When I do an lvs to look at he sizes of my devs, I get:
lvm> lvs
  WARNING: Running as a non-root user. Functionality may be unavailable.
  /dev/ram0: open failed: Operation not permitted
  /dev/dm-0: open failed: Operation not permitted
  /dev/ram1: open failed: Operation not permitted
  /dev/sda1: open failed: Operation not permitted
  /dev/dm-1: open failed: Operation not permitted
  /dev/ram2: open failed: Operation not permitted
 ....
  /dev/ram16: open failed: Operation not permitted
  /dev/ram17: open failed: Operation not permitted
...
  /dev/sdb1: open failed: Operation not permitted
  /dev/sdc6: open failed: Operation not permitted
 ...
  No volume groups found.

Thing is, ll '/dev/sd?' show:
brw-rw---- 1 root disk 8,  0 Jul  8 23:52 /dev/sda
brw-rw---- 1 root disk 8, 16 Jul  8 23:52 /dev/sdb
brw-rw---- 1 root disk 8, 32 Jul  8 16:52 /dev/sdc
brw-rw---- 1 root disk 8, 48 Jul  8 16:52 /dev/sdd

and me:
 > groups
tty disk mail wheel games audio SYSGROUP  www squid trusted named
ldap backup unix_users home private powerd ....

Notice 'disk'....

and notice how group disk has same perms has uid 'root'??

I could write to the darn things!, but all I NEED is read (hmmm
maybe I should change the perms on those devs to 640, but besides
the point)....I should be able to read them!  (any WHY is lvm
looking at all the ram disks?   Do that many people use lvm with
ram disks?  (possible, but don't see it as very useful).

So what's going on?  are all the user's associated groups being
dumped somewere?

Shouldn't have to become root just to get status of things (like
running 'top', etc...)

Re: [linux-lvm] Bug! lvs shouldn't need 'root' access

[Alasdair G Kergon]

On Sun, Jul 10, 2011 at 10:40:13AM -0700, Linda A. Walsh wrote:
> I could write to the darn things!, but all I NEED is read (hmmm

I thought so too when we first began work on LVM, but - surprising 
to me - there's been hardly any demand expressed for this feature.

The proposed method of handling this was to accept dm ioctls on
the actual devices themselves controlled by normal ioctl permissions.

Currently, you need CAP_SYS_ADMIN (and access to /dev/mapper/control).

Alasdair

Re: [linux-lvm] Bug! lvs shouldn't need 'root' access

[Linda A. Walsh]

Alasdair G Kergon wrote:
> On Sun, Jul 10, 2011 at 10:40:13AM -0700, Linda A. Walsh wrote:
>   
>> I could write to the darn things!, but all I NEED is read (hmmm
>>     
>
> I thought so too when we first began work on LVM, but - surprising 
> to me - there's been hardly any demand expressed for this feature.
>
> The proposed method of handling this was to accept dm ioctls on
> the actual devices themselves controlled by normal ioctl permissions.
>
> Currently, you need CAP_SYS_ADMIN (and access to /dev/mapper/control).
>   
----
   Why is CAP_SYS_ADMIN needed to access a disk device when device 
permissions
are already present for this?


    I can put myself for view purposes in a group disk and give an 
read-only access
to the disks as well as /dev/mapper/control.


    Being able to get status information out of the system shouldn't 
require CAP_SYS_ADMIN NOR write access -- ability t0 'read' should allow 
reading of
status.

with control by group.   CAP_SYS_ADMIN is poor control, since how do I set
CAP_SYS_ADMIN on my login and *only* have it allow reading ???

I don't.

Might as well run as root all the time.

Can this be revisited and a justification made why running "top" 
shouldn't require
sys_admin as well?

Re: [linux-lvm] Bug! lvs shouldn't need 'root' access

[Alasdair G Kergon]

On Sun, Jul 10, 2011 at 06:24:23PM -0700, Linda A. Walsh wrote:
>   Why is CAP_SYS_ADMIN needed to access a disk device when device  
> permissions
> are already present for this?

It is reading control information about the device, which is not the
same as reading the device itself.

A global CAP_SYS_ADMIN restriction is easy to implement and audit.
Anything else increases complexity and security exposure and like I
said, there's simply been hardly any demand to implement it - nor has
there been demand for proper selinux integration.

For now, configuring sudo is the closest you can get.

Alasdair

Re: [linux-lvm] Bug! lvs shouldn't need 'root' access

[Linda A. Walsh]

Alasdair G Kergon wrote:
> On Sun, Jul 10, 2011 at 06:24:23PM -0700, Linda A. Walsh wrote:
>   
>>   Why is CAP_SYS_ADMIN needed to access a disk device when device  
>> permissions
>> are already present for this?
>>     
>
> It is reading control information about the device, which is not the
> same as reading the device itself.
>
> A global CAP_SYS_ADMIN restriction is easy to implement and audit.
> Anything else increases complexity and security exposure and like I
> said, there's simply been hardly any demand to implement it - nor has
> there been demand for proper selinux integration.
>
> For now, configuring sudo is the closest you can get.
>   
----
    Which is what I'm ending up doing...

putting 'sudo' in all my scripts.

    It also means the 'lvs' command to show you how close your snapshots are
to full isn't readily available w/o sudo, (or building it into a script).

    As for reading control information -- um....is there a reason why 
the information
couldn't be exported through a /proc interface?



>   

Re: [linux-lvm] Bug! lvs shouldn't need 'root' access

[Alasdair G Kergon]

On Sun, Jul 10, 2011 at 07:31:01PM -0700, Linda A. Walsh wrote:
>    As for reading control information -- um....is there a reason why the 
> information
> couldn't be exported through a /proc interface?

Complexity of supported device construction.

We do export some basic core dm state now through sysfs.

Alasdair

Re: [linux-lvm] Bug! lvs shouldn't need 'root' access

[Linda A. Walsh]

Alasdair G Kergon wrote:
> On Sun, Jul 10, 2011 at 10:40:13AM -0700, Linda A. Walsh wrote:
>   
>> I could write to the darn things!, but all I NEED is read (hmmm
>>     
>
> I thought so too when we first began work on LVM, but - surprising 
> to me - there's been hardly any demand expressed for this feature.
>
> The proposed method of handling this was to accept dm ioctls on
> the actual devices themselves controlled by normal ioctl permissions.
>
> Currently, you need CAP_SYS_ADMIN (and access to /dev/mapper/control).
>   
Ishtar:/suse/x86_64> filecap /sbin/lvm
file                 capabilities
/sbin/lvm     sys_admin
Ishtar:/suse/x86_64> llg /dev/mapper/control
crw-rw---- 1 root disk 10, 236 Jul  8 16:52 /dev/mapper/control
(am in group disk).

---
    Doesn't work.   Still get access failures.
(open not permitted)
I got slightly further with cap_rawio, (gave more error messages).

I'm sure with enough experimenting, I could eventually find the
required set, but it seems to be a bit more than 1 cap.

Oh well, not that important...just found the caplibs on my system
and decided to give them a try...(didn't know the bins were
in yet!....only remember discussing their implementation about
11 years back.  At least ACL's were faster...


(I made the exec +eip on the binary for sys_admin and rawio, and
that wasn't sufficient).