On Sun, Jul 17, 2011 at 10:31 AM, Jack Allen
<[log in to unmask]> wrote:
> Nico:
> See answers, comments and possible questions below.
> -----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.
Good. Then I hope you've thought out the security implicatoins of
leaving your LVM "device" with a secruty structure that is unique to
your application. Oracle has historically done this, and it drives
people doing setups and ports of Oracle *insane*, and leads to people
putting in some terrible, terrible hacks to cope with, even when it
works.
>> 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
Understandable. There are real security and behavioral advantages to
udev. Even though it's made your particular application more difficult
to integrate, I think the change to keeping the permissions more
restrictive all the time was a sound one for basic security reasons.
> 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.
Great! This is an old problem with software getting more sophisticated
and security steps being taken to prevent old hacks from leaving
gaping holes.
>> 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.
Why? Is your software manipulating logical volumes for the user's
benefit, or as an initial configuration step only? I could see this
for manipulating virtualized disk images, for example, or providing
applicatoin access to the LVM snapshots or for backup systems. I've
pulled stunts like that for MySQL backups. Put MySQL on a dedicated
LVM, when necessary pause the server, do a "sync", then LVM snapshot
the database partition. Then, run the backup, very low priority, from
the mounted snapshot.
|
