Bug! lvs shouldn't need 'root' access

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:

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...)

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

----
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?

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

----
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?

Complexity of supported device construction.

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

Alasdair

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).