Nico:
	See answers, comments and possible questions below.

-----
Jack Allen


-----Original Message-----
From: Nico Kadel-Garcia [mailto:[log in to unmask]] 
Sent: Sunday, July 17, 2011 3:17 AM
To: Jack Allen
Cc: [log in to unmask]
Subject: Re: Changing mode, owner, group for /dev/*

On Thu, Jul 14, 2011 at 10:21 AM, Jack Allen
<[log in to unmask]> wrote:
> Hello:
>
>         I have an application that needs to be able to read and write a
> Logical Volume directly and it does not run as root.

Then you need to learn about suid wrappers, or possibly even "sudo" to
limit command line access to the relevant software to use the targeted
LVM as an argument.
[Jack Allen] I know all about suid wappers and I could even make the
programs them self SUID, open the device and then do setuid() back to the
real user. But I was looking for a solution that did not require making
changes to the Application itself just to be able to run on RHEL 6.X. Most
of the user of the Application never see a shell prompt to be able to use
the sudo command. Their shell is overlaid with the Application program by
doing "exec Application" in their .profile.


>         On RHEL 5.X I could change the mode, owner and group of a LV and
it
> would stay changed until the system was rebooted. This was fine because I
> could run a rc script at boot time.

Ahh. Welcome to "udev". Take a look in /etc/udev/ to learn more about
how to set up specific device ocnfigurations.
[Jack Allen] My point was there was a big change between RHEL 5.X and RHEL
6.X that has caused me a problem. Yes, that is the price of progress. I have
and I now have a udev rule that only changes the mode, owner and group of
certain LVs based on the name. But again that was something I did not have
to do in RHEL 5.X and means more things to setup when installing the
Application.

>         On RHEL 6.X if I do the same thing, as soon as the application
opens
> the LV for writing the first time the mode, owner and group are changed
> back. This means the LV is not accessible by other application processes.

Nor should it be, in general. The fact that it's an LV is irrelevant,
it's a "block device" as far as the kernel and libc and udev care.
[Jack Allen] Yes but LVs is what the Application uses, not block device like
sdb. So it is specific block device names that I needed to have a certain
mode, owner, group.



>         I know this is a Scientific-Linux list, but because it is based on
> Red Hat the problem and solution would be the same and I have post the
same
> thing on a Red Hat list and gotten no replies, I thought I would try here.
I
> don’t know if it is selinux or udev that is doing this. I am sure someone
> may have some questions and want more details and I will provide them if
> requested. I just did not want to take up a lot of space with all kinds of
> examples, etc.
>
> I cannot start supporting the application on RHEL 6.X until I find a
> solution to this problem.

You can test by turning off SELinux, but that wouldn't normally reset
ownership. It would control access according to some complex rules,
but not reset ownership.
[Jack Allen] I completely disabled SELinux and it did not make any
difference. It is udev that is make the changes which is functioning
different in RHEL 6.X than it did in RHEL 5.X. Again the price of progress.

I'd strongly consider sidestepping this problem with "sudo", depending
on what the programs are that need LVM access. Virtualization
accessible block devices, for example, might be much safer if you cna
restrict the programs and users who can ruun them.
[Jack Allen] See my comments about sudo above. And yes, I could put sudo in
the .profile as well. But the Application users also can create other files
from within the Application then the files would then be owned by root,
which not desired.


> Thanks
>
> Jack Allen