Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

Hi

On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote:
> I was recently working on gcc builds and this disagreement currently
> makes stuff unbuildable. Hence I looked into solutions and/or
> workarounds.

Care to just share what you actually found?  Where is it broken and how
to see this?

Because this whole thing started with "it is broken, but I won't tell
you where or what or how".

> On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> > > You just said that the search path used during the build of the
> > > toolchain and the one for everything else are unrelated.  So you are
> > > free to create $BUILD/tmp-include with symlinks for asm, asm-generic,
> > > linux.
> > > 
> > > The toolchain as installed already finds all headers.  So I still don't
> > > see why we need this in the final system.
> > 
> > I find this argument fairly convincing and hope Matthias also does.
> 
> As a result, I implemented the proposed change and am attaching it for
> discussion here. I've implemented it in a way that if there is a sysroot
> linux header installation, it'll be preferred. Do you see any downsides
> of this approach?

I wonder now.  How would that ever work for the native build?  Or does
the native build already do those symlinks?  Or are native and cross
configured differently?  Or is that a weird difference in gcc itself?

Bastian

-- 
Oblivion together does not frighten me, beloved.
-- Thalassa (in Anne Mulhall's body), "Return to Tomorrow",
   stardate 4770.3.

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Bastian Blank]

Hi Gunar

On Thu, May 18, 2023 at 12:14:42PM -0600, Gunnar Wolf wrote:
> dpkg has many bits that make it special. It has been discussed whethe
> dpkg should be a native package or it should become non-native; if it
> were non-native, having a patch that contradicts the upstream author's
> wishes would be easier (and I'm not saying that I'd be up for patching
> this warning out as it is).

But why does the state of the package (native vs non-native) can have
any effect on a CTTE decision?  Or do you want to say I can block CTTE
from reaching any kind of decision just by uploading a package as
native?  Sorry, but this does not compute.

> If we were to force a patch silencing out this warning right now and
> for all of the Bookworm cycle, and the dpkg authors disagree with it,
> they could remove (even omit to include it) in any updates.

Sure, but this is a direct violation of a CTTE decision.  How often do
you think someone could do that?

Bastian

-- 
"Life and death are seldom logical."
"But attaining a desired goal always is."
-- McCoy and Spock, "The Galileo Seven", stardate 2821.7

Bug#1007717: Native source package format with non-native version

[Bastian Blank]

On Tue, Mar 15, 2022 at 04:29:17PM +, Ian Jackson wrote:
>  1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>  2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.

One additional point:
We currently have packages in the archive, which must be "3.0 (native)",
but are generated from other packages: all the secure boot signed
packages.

Example source package:
| Package: linux-signed-amd64
| Version: 5.17~rc8+1~exp1

is generated from binary package:
| Package: linux-image-amd64-signed-template
| Version: 5.17~rc8-1~exp1

Generating the source package needs to munge the version, just to
appease that version restriction.  This also means, adding dependencies
on versions is difficult, as both versions sort differently.  And bugs
are assigned to wrong versions, so version tracking does not work.

Regards,
Bastian

-- 
Kirk to Enterprise -- beam down yeoman Rand and a six-pack.

Bug#978636: move to merged-usr-only?

[Bastian Blank]

On Tue, Jan 26, 2021 at 09:56:46AM +, Simon McVittie wrote:
> Oh, I see. So when you say "both" in 1a, you're referring to the overall
> system - like the fact that we have both /bin/bash and /usr/bin/perl.

Yes.

> I don't see how we can force all packages to only ship files in /usr/*
> (your 1b), except by either *first* moving to merged-/usr-via-aliasing

Which is the easy part.  We say: other systems are not longer supported
after date X.  Otherwise we will never get it done.

> * bash and libc6 are Essential
>   (so are other packages, but these two are enough to demonstrate my point)
> * bash has traditionally shipped /bin/bash, and this is part of its
>   Essential interface (other packages ship #!/bin/bash scripts)
> * libc6 ships /lib/ld-linux.so.2 and other architectures' equivalents,
>   and this is part of its Essential interface
>   (other i386 packages have ELF interpreter /lib/ld-linux.so.2)
> * Essential packages are required to be functional after being merely
>   unpacked, not configured (otherwise debootstrap can't work)
> 
> So if we unpack bash and libc6:i386, but do not configure them, /bin/bash
> and /lib/ld-linux.so.2 must exist in the resulting chroot.

Before unpacking those packages, both /bin and /lib symlinks must
already exist, because it's past the cutoff date of non-aliased support.

> However, if that chroot is in layout 2a or 2b, and bash's filesystem tarball
> contains ./usr/bin/bash, then its Essential interface is incomplete:
> there will be no /bin/bash symlink until the package is configured
> (maintainer scripts are run).

Option 2 doesn't provide us any benefit.  The world already implemented
option 1.

> I agree that your 1b is preferable *eventually*, but I think your 1a is
> necessary as a stepping-stone to get there.

We are already effectively at 1a.  So we need to decide if we want 1b to
fix the fallout.

> The only other option that I can see is for dpkg to gain the ability to
> populate what we might call the "mergeable" directories (/bin, /sbin,
> /lib*) in a purely declarative way, during unpack.

No, because we want to support /usr only systems or snapshots, where /
is populated on first boot.  That's where the world is going.

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Bug#978636: move to merged-usr-only?

[Bastian Blank]

On Tue, Jan 26, 2021 at 09:01:12AM +, Simon McVittie wrote:
> On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote:
> > On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote:
> > > Some developers seem to be using "merged /usr" to refer to multiple
> > > concrete layouts:
> > > 1. an arrangement where all regular files that have traditionally been
> > >in /bin, /sbin, /lib and /lib64 are physically located in /usr,
> > >with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib,
> > >/lib64 -> usr/lib64
> > >(this is what usrmerge, debootstrap --merged-usr and Fedora do; dpkg
> > >maintainer Guillem Jover refers to this as "merged /usr via aliased
> > >directories" which seems like a good unambiguous term)
> > 
> > Aren't there two sub-solutions?
> > 
> > 1a. with packages shipping files both in /bin und /usr/bin.
> > 1b. with packages shipping files only in /usr/bin.
> 
> What precisely do you mean by "shipping files"?

"We allow packages to ship files".  So either we force all packages to
only ship files in /usr/*, instead of e.g. /bin.  Or we continue with
status quo, where packes may use either /bin or /usr/bin, which is part
of the current mess.

Bastian

-- 
"That unit is a woman."
"A mass of conflicting impulses."
-- Spock and Nomad, "The Changeling", stardate 3541.9

Bug#978636: move to merged-usr-only?

[Bastian Blank]

On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote:
> Some developers seem to be using "merged /usr" to refer to multiple
> concrete layouts:
> 1. an arrangement where all regular files that have traditionally been
>in /bin, /sbin, /lib and /lib64 are physically located in /usr,
>with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib,
>/lib64 -> usr/lib64
>(this is what usrmerge, debootstrap --merged-usr and Fedora do; dpkg
>maintainer Guillem Jover refers to this as "merged /usr via aliased
>directories" which seems like a good unambiguous term)

Aren't there two sub-solutions?

1a. with packages shipping files both in /bin und /usr/bin.
1b. with packages shipping files only in /usr/bin.

Bastian

-- 
Klingon phaser attack from front!
100% Damage to life support

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Bastian Blank]

On Tue, Jun 27, 2017 at 11:31:57AM -0700, Josh Triplett wrote:
> On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson  wrote:
> > I could arrange for the relevant grub2 postinst scripts to remove
> > /etc/default/grub.d/init-select.cfg entirely when appropriate conditions
> > apply.  In addition to a self-defence argument, this is further
> > justified by the fact that grub2 now provides a similar facility of its
> > own as of 2.02~beta2-20: if other init daemons are installed, then
> > grub-mkconfig generates additional menu items for them (although there
> > are no arrangements to migrate the default choice from
> > /etc/default/init).  This would still violate policy §10.7.3/10.7.4,
> > although it seems to be the favoured option of the debian-devel thread,
> > and it is the least bad option I can see so far.
> 
> This seems very reasonable. However, to avoid even the remote chance of
> losing user data, you should include hashes of all shipped versions of
> init-select.cfg or possible generated versions of it for various init
> systems, and if the file doesn't match one of those, move it aside to a
> backup location and provide a notice to the user that you've done so.

We already have such a functionality available via
dpkg-maintscript-helper.

Bastian

-- 
There are some things worth dying for.
-- Kirk, "Errand of Mercy", stardate 3201.7

Re: bastardizing packages or stepping down

[Bastian Blank]

On Fri, Mar 06, 2015 at 10:46:26AM +0100, Kurt Roeckx wrote:
 I didn't see any request to make sure the chroots are updated.
 Not having read the whole thing, would this solve your problem?

We have 2015, we even have snapshot aware filesystems to make it safe.
Why for gods sake is this still a manual task?

Bastian

-- 
Many Myths are based on truth
-- Spock, The Way to Eden,  stardate 5832.3


signature.asc
Description: Digital signature

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Bastian Blank]

On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
 On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
  - lvm2.service is statically hooked to local-fs.target, as all local
mounts.
 lvm2.service is not a local mount, so that is not really a justification for
 enabling the service statically.

Please show me a better target.  This is what the generator does, so I
assume there exists none.

  +ExecStartPre=/bin/udevadm settle
 Please don't run udevadm directly. This is a udev command.

Can you please describe what will be broken by this?

 Wants=systemd-udev-settle.service
 After=systemd-udev-settle.service ...
 (as the original .service file does).

The generated service files uses both variants:
- The pre-cryptsetup and pre-local-fs services uses
  systemd-udev-settle.service.
- The pre-remote-fs service, which is not included here currently, uses
  ExecStartPre.

 Wants= will make sure the systemd-udev-settle.service is started
 dynamically and After= ensures the correct ordering.

It only makes sure that systemd-udev-settle.service was started
somewhere _before_.  It does however not make sure it is called again
for the second round or third round.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, The City on the Edge of Forever, stardate 3134.0


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119105901.ga14...@mail.waldi.eu.org

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Bastian Blank]

On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote:
 --- /dev/null
 +++ b/debian/lvm2-activation-early.service

Wrong name.

 +[Unit]
 +Description=Activation of LVM2 logical volumes
 +Documentation=man:lvm(8) man:vgchange(8)
 +DefaultDependencies=no
 +After=systemd-udev-settle.service
 +Before=cryptsetup.target

This have to be cryptdisks.service

 +++ b/debian/lvm2-activation.service

Wrong name.

 +After=lvm2-activation-early.service cryptsetup.target

The same: cryptdisks.service

 +usr/lib/tmpfiles.d/lvm2.conf

Undocumented in the changelog.

Bastian

-- 
Punishment becomes ineffective after a certain point.  Men become insensitive.
-- Eneg, Patterns of Force, stardate 2534.7


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118111043.ga11...@mail.waldi.eu.org

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Bastian Blank]

Untested patch:

- Static services with the correct name.
- lvm2.service is statically hooked to local-fs.target, as all local
  mounts.
- lvm2-early.service is statically hooked to cryptsetup.target, as all
  crypto devices.

| drwxr-xr-x root/root 0 2014-01-18 12:32 ./lib/systemd/
| drwxr-xr-x root/root 0 2014-01-18 12:49 ./lib/systemd/system/
| -rw-r--r-- root/root   310 2014-01-18 12:34 
./lib/systemd/system/lvm2-early.service
| -rw-r--r-- root/root   301 2014-01-18 12:48 
./lib/systemd/system/lvm2.service
| drwxr-xr-x root/root 0 2014-01-18 12:49 
./lib/systemd/system/cryptsetup.target.wants/
| drwxr-xr-x root/root 0 2014-01-18 12:49 
./lib/systemd/system/local-fs.target.wants/
| lrwxrwxrwx root/root 0 2014-01-18 12:49 
./lib/systemd/system/cryptsetup.target.wants/lvm2-early.service - 
../lvm2-early.service
| lrwxrwxrwx root/root 0 2014-01-18 12:49 
./lib/systemd/system/local-fs.target.wants/lvm2.service - ../lvm2.service

Index: 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service
===
--- 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service  
(revision 0)
+++ 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service  
(working copy)
@@ -0,0 +1 @@
+link ../lvm2-early.service
\ No newline at end of file

Property changes on: 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service
___
Added: svn:special
## -0,0 +1 ##
+*
\ No newline at end of property
Index: debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service
===
--- debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service  
(revision 0)
+++ debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service  
(working copy)
@@ -0,0 +1 @@
+link ../lvm2.service
\ No newline at end of file

Property changes on: 
debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service
___
Added: svn:special
## -0,0 +1 ##
+*
\ No newline at end of property
Index: debian/tree/lvm2/lib/systemd/system/lvm2-early.service
===
--- debian/tree/lvm2/lib/systemd/system/lvm2-early.service  (revision 0)
+++ debian/tree/lvm2/lib/systemd/system/lvm2-early.service  (working copy)
@@ -0,0 +1,11 @@
+[Unit]
+Description=Activation of LVM2 logical volumes
+Documentation=man:lvm(8) man:vgchange(8)
+DefaultDependencies=no
+After=systemd-udev-settle.service
+Before=cryptsetup.target local-fs.target shutdown.target
+
+[Service]
+ExecStartPre=/bin/udevadm settle
+ExecStart=/sbin/lvm vgchange -aay --sysinit
+Type=oneshot
Index: debian/tree/lvm2/lib/systemd/system/lvm2.service
===
--- debian/tree/lvm2/lib/systemd/system/lvm2.service(revision 0)
+++ debian/tree/lvm2/lib/systemd/system/lvm2.service(working copy)
@@ -0,0 +1,11 @@
+[Unit]
+Description=Activation of LVM2 logical volumes
+Documentation=man:lvm(8) man:vgchange(8)
+DefaultDependencies=no
+After=lvm2-early.service cryptsetup.target
+Before=local-fs.target shutdown.target
+
+[Service]
+ExecStartPre=/bin/udevadm settle
+ExecStart=/sbin/lvm vgchange -aay --sysinit
+Type=oneshot


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118122041.ga11...@mail.waldi.eu.org

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Bastian Blank]

On Mon, Dec 02, 2013 at 03:11:03PM -0800, Don Armstrong wrote:
 On Mon, 02 Dec 2013, Bastian Blank wrote:
  On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote:
   Bastian: Would such a patch be acceptable in principle?
  After systemd was fixed, yes.
 Can you let me know which part of systemd needed to be fixed? [What bug#
 is this?]

It is #720850.  systemd breaks backward compatibility.

 Can you also clarify for me why the patch needs to wait for systemd to
 be fixed?

Because the lvm2 service would fail the same way then the init script.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
-- Kirk, The Gamesters of Triskelion, stardate 3211.7


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140116134756.ga2...@mail.waldi.eu.org

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Bastian Blank]

On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote:
 Bastian: Would such a patch be acceptable in principle?

After systemd was fixed, yes.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, Mirror, Mirror, stardate unknown


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131202225150.ga9...@mail.waldi.eu.org

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Bastian Blank]

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
 and devmapper reading this thread ?  If not we should make sure that
 they look at it.

There are 5 reverse dependencies to devmapper: lvm2, lilo,
multipath-tools, dmraid, cryptsetup.

I can speak for lvm2 and multipath-tools. lilo is not affected by this
problem, as it only uses them to find block numbers. The remaining
packages are dmraid and cryptsetup.

I don't think they got knowledge about that thread. Can you post a
pointer?

 I'm also encouraged by the fact that you've written patches at all;
 this suggests that you do seem to be taking the matter seriously,

I developed the idea for this fix some months ago, but never found the
time to implement it. So I should have refrained from tagging the bugs
wontfix.

The lvm2 patch lacks one additional functionality where I don't know if
it is possible to implement: I want to make the permissions dependent on
the metadata tags or just record them in the metadata.

 although your comments don't always give that impression.

This may be a sign for beeing overloaded. I just try to finish my
prediploma and the mathematics course needs a lot of work.

 If you're finding it difficult to write long and coherent explanations
 in English please feel free to write in German.  My German is probably
 good enough to understand your points if you spell them out clearly
 (and at length!) and I would be happy to try to act as an
 intermediary.

Thank you for the offer.

Bastian

-- 
No one may kill a man.  Not for any purpose.  It cannot be condoned.
-- Kirk, Spock's Brain, stardate 5431.6


signature.asc
Description: Digital signature

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Bastian Blank]

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 setting in the
   udev config)
  A chown/chmod of the device is not scalable or practical.
 
  You recreate the complete /dev?
 
 lvcreate/vgchange and related commands will create the devices with
 the default ownership, and hence require *manual* correction after
 their creation.  Thus chown/chmod are not practical for anything but
 tiny and unchanging installations.

Hu? lvcreate don't create static devices.

 
  a new LV, the permissions will be wrong.  If I run vgchange, the
  permissions will be wrong.  This is not a solution.
 
  And I don't speak about libdevmapper managed device.
 
 Please could you clarify?  What *are* you speaking about.  I'm
 referring to the fact that when I create or change an LVM LV, I have
 to manually correct the permissions (on both static and udev managed
 systems).

Lets quote myself:
|  means in my context: chmod of static devices or a MODE setting in the
| udev config)

This does not qualify dm devices.

  SUBSYSTEM==block, MODE=0600
 
 That changes the default permissions for block devices, but this is
 not what I meant.
 
 How do I get device-mapper devices to be created by udev, along with
 the related symlinks?  The rule you suggest above does not in any way
 affect the *device-mapper* device permissions or ownership, which is
 the problem at hand:

KERNEL==dm-[0-9]*, ACTION==add, PROGRAM=/sbin/dmsetup info -c 
--noopencount --noheadings -o name -j %M -m %m, SYMLINK=disk/by-name/%c

as shipped by suse.

 Also, you have not addressed the case where udev is not in use: the
 ownership and permissions are still wrong.

The settings are a secure default.

Anyway, what are the problems with a default of 666? It fixes any of the
problems.

Bastian

-- 
The heart is not a logical organ.
-- Dr. Janet Wallace, The Deadly Years, stardate 3479.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Bastian Blank]

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 checks are only done on open.

 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 people are an arbitrary subset?

 Is there something about this question I'm asking which doesn't make
 sense to you?

Yes, there seems to be one tool (named amanda) which uses the devices
directly without the posix compilant capability CAP_DAC_READ which is
there for backup reasons.

 You seem to be asserting: a malicious person who handles backups could
 use the disk group to obtain root access, so you should force backup programs
 to run as root.  But that does not seem to be a reasonable position:

I never said, that they should run as root.

 (1) There are risks other than a malicious people -- by ensuring backup 
 programs
 don't have to run as root, we minimize the risks that such programs will do
 something they weren't designed to do.

Many tools have additional checks to never do anything as root. Now you
have just another user with the same rights.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Bastian Blank]

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 solution)
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 by upstream and search for some other people
to test them, if this solution is acceptable.

Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, The Menagerie, stardate 3012.4
=== debian/changelog
==
--- debian/changelog(revision 206)
+++ debian/changelog(local)
@@ -1,3 +1,9 @@
+devmapper (2:1.02.02-1.0permission.1) UNRELEASED; urgency=low
+
+  * Make device mode modificable.
+
+ -- Bastian Blank [EMAIL PROTECTED]  Fri, 23 Dec 2005 20:03:04 +0100
+
 devmapper (2:1.02.02-1) unstable; urgency=low
 
   * New upstram version. 
=== debian/rules
==
--- debian/rules(revision 206)
+++ debian/rules(local)
@@ -117,7 +117,7 @@
dh_link -a
dh_compress -a
dh_fixperms -a
-   dh_makeshlibs -a
+   dh_makeshlibs -a -V 'libdevmapper1.02 (= 2:1.02.02-1.0permission.1)'
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
=== dmsetup/dmsetup.c
==
--- dmsetup/dmsetup.c   (revision 206)
+++ dmsetup/dmsetup.c   (local)
@@ -88,6 +88,9 @@
EXEC_ARG,
MAJOR_ARG,
MINOR_ARG,
+   UID_ARG,
+   GID_ARG,
+   MODE_ARG,
NOHEADINGS_ARG,
NOLOCKFS_ARG,
NOOPENCOUNT_ARG,
@@ -390,6 +393,15 @@
if (_switches[MINOR_ARG]  !dm_task_set_minor(dmt, _values[MINOR_ARG]))
goto out;
 
+   if (_switches[UID_ARG]  !_dm_task_set_uid(dmt, _values[UID_ARG]))
+   goto out;
+
+   if (_switches[GID_ARG]  !_dm_task_set_gid(dmt, _values[GID_ARG]))
+   goto out;
+
+   if (_switches[MODE_ARG]  !_dm_task_set_mode(dmt, _values[MODE_ARG]))
+   goto out;
+
if (_switches[NOOPENCOUNT_ARG]  !dm_task_no_open_count(dmt))
goto out;
 
@@ -1292,7 +1304,8 @@
 
 static struct command _commands[] = {
{create, dev_name [-j|--major major -m|--minor minor]\n
- \t  [-u|uuid uuid] [--notable] [table_file],
+ \t  [-u|uuid uuid] [-U|--uid uid] [-G|--gid 
gid]\n
+ \t  [-M|--mode mode] [--notable] [table_file],
 1, 2, _create},
{remove, device, 0, 1, _remove},
{remove_all, , 0, 0, _remove_all},
@@ -1420,6 +1433,9 @@
{exec, 1, ind, EXEC_ARG},
{major, 1, ind, MAJOR_ARG},
{minor, 1, ind, MINOR_ARG},
+   {uid, 1, ind, UID_ARG},
+   {gid, 1, ind, GID_ARG},
+   {mode, 1, ind, MODE_ARG},
{noheadings, 0, ind, NOHEADINGS_ARG},
{nolockfs, 0, ind, NOLOCKFS_ARG},
{noopencount, 0, ind, NOOPENCOUNT_ARG},
@@ -1478,10 +1494,14 @@
 
optarg = 0;
optind = OPTIND_INIT;
-   while ((ind = -1, c = GETOPTLONG_FN(*argc, *argv, cCj:m:no:ru:v,
+   while ((ind = -1, c = GETOPTLONG_FN(*argc, *argv, cCj:G:m:M:no:ru:U:v,
long_options, NULL)) != -1) {
if (c == 'c' || c == 'C' || ind == COLS_ARG)
_switches[COLS_ARG]++;
+   if (c == 'G' || ind == GID_ARG) {
+   _switches[GID_ARG]++;
+   _values[GID_ARG] = strtol(optarg, NULL, 10);
+   }
if (c == 'r' || ind == READ_ONLY)
_switches[READ_ONLY]++;
if (c == 'j' || ind == MAJOR_ARG) {
@@ -1492,6 +1512,10 @@
_switches[MINOR_ARG]++;
_values[MINOR_ARG] = atoi(optarg);
}
+   if (c == 'M' || ind == MODE_ARG) {
+   _switches[MODE_ARG]++;
+   _values[MODE_ARG] = strtol(optarg, NULL, 8);
+   }
if (c == 'n' || ind == NOTABLE_ARG)
_switches[NOTABLE_ARG]++;
if (c == 'o' || ind == OPTIONS_ARG) {
@@ -1504,6 +1528,10 @@
_switches[UUID_ARG]++;
_uuid = optarg;
}
+   if (c == 'U' || ind == UID_ARG) {
+   _switches[UID_ARG]++;
+   _values[UID_ARG] = strtol(optarg, NULL, 10);
+   }
if ((ind == EXEC_ARG)) {
_switches[EXEC_ARG

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Bastian Blank]

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 overwrite them on my machines.
 
 And what is your reason for being unwilling to use the same procedure
 on devmapper disks?

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
udev config)

 Personally, I'm using a system where the only way to obtain root access
 is to log in as root -- there's no privileges gained through suid binaries.

Err? Write access to the device of a mounted filesystem is a way to gain
root if you don't disable several options.

Bastian

-- 
Beauty is transitory.
Beauty survives.
-- Spock and Kirk, That Which Survives, stardate unknown


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Bastian Blank]

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 rejected, no reason given
   Certainly I agree that the defaults should be changed.
  At least in my point of view, a default is something which can be
  changed easily, maybe in a config file. In this case, it is no default,
  it is the value which anything gets.
 You seem to be saying that there is no way to override the setting.
 Which proposed setting are you talking about here - the change in the
 call to configure, or some other change ?

The first.

 How do you think this problem should be solved ?

Add an interface to change the setting on device creation and delegate
the problem to the tools.

I've also seen the suggestion that we should have a explicit
technical policy that block devices should default to having 660
permissions with owner root and group disk.  [...]
  This breaks anything which wants to use group cdrom for cdrom access
  without manual intervention.
 Obviously the policy language would have to be carefully worded to
 ensure that it applied to disks and not (eg) to cdrom devices.

devmapper don't provide disks. It provides a view (in the SQL meaning)
of block devices.

 Are you saying that the current default permissions on (eg) /dev/hda*
 are insecure and therefore wrong ?

Yes, I overwrite them on my machines.

 If they are, what significant good
 does it do to make the lvm devices inaccessible to group disk (since
 it is possible to avoid going through LVM to access the disks
 directly).

deviver-mapper uses major and minor for the communication, only the
userspace tools uses the devices to read data or just map them to the
device number.

 Is the problem with your participation in this discussion that English
 isn't your native language ?

Yes, it is one.

Bastian

-- 
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, Patterns of Force, stardate 2534.7