Kernel Device Mapper header files
libdevmapper1.02 - The Linux Kernel Device Mapper userspace library
libdevmapper1.02-udeb - The Linux Kernel Device Mapper userspace library (udeb)
Closes: 316883 329409 341901 342455
Changes:
devmapper (2:1.02.07-1) unstable; urgency=low
.
* New upstream version
Your message dated Sat, 10 Jun 2006 14:47:10 -0700
with message-id [EMAIL PROTECTED]
and subject line Bug#342455: fixed in devmapper 2:1.02.07-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case
Kernel Device Mapper header files
libdevmapper1.02 - The Linux Kernel Device Mapper userspace library
libdevmapper1.02-udeb - The Linux Kernel Device Mapper userspace library (udeb)
Closes: 316883 329409 341901 342455
Changes:
devmapper (2:1.02.07-1) unstable; urgency=low
.
* New upstream version
Kernel Device Mapper header files
libdevmapper1.02 - The Linux Kernel Device Mapper userspace library
libdevmapper1.02-udeb - The Linux Kernel Device Mapper userspace library (udeb)
Closes: 316883 329409 341901 342455
Changes:
devmapper (2:1.02.07-1) unstable; urgency=low
.
* New upstream version
Anthony Towns aj@azure.humbug.org.au writes:
So, it seems like we have the following opinions:
In the long term, have fine grained control that leaves disks as
root:disk 0660, and other devices with other appropriate groups.
-- in favour: everyone?
Immediately, until the
On 2/10/06, Bastian Blank [EMAIL PROTECTED] wrote:
On Fri, Feb 10, 2006 at 04:40:22PM -0800, Steve Langasek wrote:
Otherwise, having access to the underlying block devices means having access
to meddle with anything on the LVM devices as well.
And who says that anyone have access to the
On Sat, Feb 11, 2006 at 07:33:34PM -0500, Raul Miller wrote:
On 2/10/06, Steve Langasek [EMAIL PROTECTED] wrote:
... follow-up to self: given that crypt-dm sits on top of devmapper, it is
indeed plausible that one would want to prevent members of group disk from
reading the decrypted
On Sat, Feb 11, 2006 at 04:47:16PM -0800, Steve Langasek wrote:
On Sat, Feb 11, 2006 at 07:33:34PM -0500, Raul Miller wrote:
On 2/10/06, Steve Langasek [EMAIL PROTECTED] wrote:
... follow-up to self: given that crypt-dm sits on top of devmapper, it is
indeed plausible that one would want
Raul Miller [EMAIL PROTECTED] writes:
On 2/2/06, Roger Leigh [EMAIL PROTECTED] wrote:
It's nearly a month since the last mail to this bug. Is this getting
close to being resolved?
Did you notice the content of the message before yours in this bug's
history? It's from Bastian Blank, and
On 2/10/06, Roger Leigh [EMAIL PROTECTED] wrote:
I did read this, and I'm happy progress is being made. However, the
default is still currently wrong in unstable, and the fix is a simple
change to configure in debian/rules.
I agree that the devmapper default should match other
debian
On 2/10/06, Ian Jackson [EMAIL PROTECTED] channelled:
The proposed change to devmapper changes the permissions for all block
devices, doesn't it ? Whereas the other debian defaults vary from one
kind of device to another. For example, floppies are g+w floppy.
The change to devmapper is
On Fri, Feb 10, 2006 at 04:40:22PM -0800, Steve Langasek wrote:
On Fri, Feb 10, 2006 at 04:29:39PM +, Ian Jackson wrote:
Raul Miller writes (Re: #342455):
I agree that the devmapper default should match other
debian defaults, and vice-versa.
If I may try to channel Bastian Blank
On Sat, Feb 11, 2006 at 01:46:56AM +0100, Bastian Blank wrote:
On Fri, Feb 10, 2006 at 04:40:22PM -0800, Steve Langasek wrote:
Otherwise, having access to the underlying block devices means having access
to meddle with anything on the LVM devices as well.
And who says that anyone have
On Fri, Feb 10, 2006 at 04:48:25PM +, Ian Jackson wrote:
It's also inconsistent over time on many single machines.
I agree that the current situation is unsatisfactory. But I think (at
the moment, at least) that it should be fixed by adopting Bastian's
code fragments with an appropriate
On 2/2/06, Roger Leigh [EMAIL PROTECTED] wrote:
It's nearly a month since the last mail to this bug. Is this getting
close to being resolved?
Did you notice the content of the message before yours in this bug's
history? It's from Bastian Blank, and includes among other things the
statement:
Bastian Blank writes (Bug#342455: tech-ctte: Ownership and permissions of
device mapper block devices):
4) the two attached patches:
- devmapper: export functions to set permissions
- lvm2: add a config entry to overwrite the permissions for new
devices
I just try to get it acked
On Tue, Jan 03, 2006 at 03:26:30PM +, Ian Jackson wrote:
Thanks for your patches. I don't have time right know to look at the
technicalities in detail.
I did not get any response about the patches from upstream yet.
Do we have all of the relevant Debian LVM
On 12/23/05, Bastian Blank [EMAIL PROTECTED] wrote:
Anyway, what are the problems with a default of 666? It fixes any
of the problems.
Is this a serious question?
Access to group disk can be easily controlled by the
system administrator. On some systems, only root
has this access, on other
On Sat, Dec 17, 2005 at 03:09:37PM +, Roger Leigh wrote:
Bastian Blank [EMAIL PROTECTED] writes:
On Sat, Dec 17, 2005 at 12:41:17PM +, Roger Leigh wrote:
Which procedure? You seem to know something I don't know. (Overwrite
means in my context: chmod of static devices or a MODE
On Tue, Dec 20, 2005 at 12:35:00AM -0500, Raul Miller wrote:
I'm trying to ask why you are unwilling to have devmapper disks provide
a default of root.disk 660? Why can't you allow that to be the default?
You can always make permissions less strict, you can't make them more
strict, as the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bastian Blank [EMAIL PROTECTED] writes:
On Tue, Dec 20, 2005 at 12:35:00AM -0500, Raul Miller wrote:
Is there some reason you can't have implement your personally preferred
policy of root.root 600 on just your own system? Is there some reason
* Bastian Blank ([EMAIL PROTECTED]) wrote:
Is there some reason you can't have implement your personally preferred
policy of root.root 600 on just your own system? Is there some reason
for projecting your personal policies incompletely onto an arbitrary
subset of debian's users?
Hu? 10
On Sun, Dec 11, 2005 at 04:47:26PM -0500, Raul Miller wrote:
Here's what I currently see suggested:
1) change devmapper defaults -- patch rejected, no reason given
2) explicitly use udev -- problem, this doesn't work for 2.4 kernels
(2.4 used devfs)
3) avoid using devmapper (but this is not a
On 12/17/05, Bastian Blank [EMAIL PROTECTED] wrote:
On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote:
On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote:
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
Are you saying that the current default permissions on (eg)
On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote:
On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote:
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
Are you saying that the current default permissions on (eg) /dev/hda*
are insecure and therefore wrong ?
Yes, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bastian Blank [EMAIL PROTECTED] writes:
On Sat, Dec 17, 2005 at 12:41:17PM +, Roger Leigh wrote:
Which procedure? You seem to know something I don't know. (Overwrite
means in my context: chmod of static devices or a MODE setting in the
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
Bastian Blank writes (Re: Bug#342455: tech-ctte: Ownership and permissions
of device mapper block devices):
On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote:
[Raul Miller:]
1) change devmapper defaults -- patch
On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote:
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
Are you saying that the current default permissions on (eg) /dev/hda*
are insecure and therefore wrong ?
Yes, I overwrite them on my machines.
And what is your reason for being
Bastian Blank writes (Re: Bug#342455: tech-ctte: Ownership and permissions of
device mapper block devices):
On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote:
[Raul Miller:]
1) change devmapper defaults -- patch rejected, no reason given
Certainly I agree that the defaults
Raul Miller writes (Bug#342455: tech-ctte: Ownership and permissions of device
mapper block devices):
I've been looking at these bugs, and I can see no good reason for the 600
permissions, nor the reason to avoid using the disk group.
I basically agree, but I'm going to try to play devil's
I agree with your technical assessment, Ian.
On 12/13/05, Ian Jackson [EMAIL PROTECTED] wrote:
I think the committee's ruling should explicitly castigate
the devmapper maintainer for failing to engage constructively with any
of the submitters.
But I disagree with this. I think such a
Guy Maor writes (Bug#342455: tech-ctte: Ownership and permissions of device
mapper block devices):
I agree with your technical assessment, Ian.
Do you have an opinion about 660 vs 640 ? And the question of
equivalence to root ?
On 12/13/05, Ian Jackson [EMAIL PROTECTED] wrote:
I think
I've been looking at these bugs, and I can see no good reason for the 600
permissions, nor the reason to avoid using the disk group.
There also seems to be some huge confusion about where responsibility for
setting permissions and group should be handled.
Here's what I currently see suggested:
33 matches
Mail list logo
