Re: no deprecation of /usr as a standalone filesystem
Marco d'Itri wrote: On Jun 02, Giacomo A. Catenazzi c...@debian.org wrote: - there is still a close windows in initram, and possibility at early rc scripts. No. - /var is still not mounted, so programs could not write they status, nor log failures So programs which have such requirements need to take care of waiting long enough. e.g. the ifupdown wrapper script waits for /dev/log to appear. - care about security implication: user that triggers events before system is fully up (e.g. busy resources) I see no security implications. Wrong udev script could make busy resources, mounting point, ... which cause an unexpected execution path (when there are bugs on udev scripts). We cannot log problems, and we cannot reproduce errors, because it is difficult to plug again devices at the exact same time of previous run. Some newbies (and others) will have wrong permissions in udev configuration (google for udev rules, and you will see ugly and unsecure udev rules). Such rules are not done by you or Debian, but we cannot ignore that people do thing wrongly and publish it. So the security rule I recently see in a RFC (which disabled some cryptography algorithms): seldom run paths should be considered insecure - and I think other usual system assumption are not fulfilled, so maintainers should be trained on what they could assume on udev sequence. Maintainers who have doubts can ask for help here or by private mail. For these reasons, I think only few events (explicitly ack by maintainers) should be handled by early boot, and the rest run later (udev events are already asynchronous by definition). There is no need for this. More I think about the specific issue, the more I think we should not accept hotplug before very late boot process: kernel and boot people hate asynchronous boot process, because it boot process has bugs, but it is very difficult to track such bugs. With udev we have the same cases: how many of us test every device with early plug? Do we really need to handle such hotplugs? We could require that all boot hardwares must be available short after boot loader. The later plugged hardware will be shown only later, when the system in up. I see no disadvantage, and make thing easier, more testable (and I think also more secure). But nobody commented with the orthogonal question: could we handle /usr specially and mount at the beginning? We eventually lose networked /usr, but we can still use plain non-crypted read-only /usr as an other partition. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Jun 04, Giacomo Catenazzi c...@debian.org wrote: Do we really need to handle such hotplugs? We could require that all boot hardwares must be available short after boot loader. The later plugged hardware will be shown only later, when the system in up. I see no disadvantage, and make thing easier, more testable (and I think also more secure). The complexity required to decide and configure which events should be delayed and when, and implementing the infrastructure needed to do this. If you have further opinions about this please bring them to the upstream mailing list. -- ciao, Marco signature.asc Description: Digital signature
Re: no deprecation of /usr as a standalone filesystem
Ken Bloom kbl...@gmail.com writes: Josselin Mouette j...@debian.org wrote: Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit : What has the initramfs got to do with this? For / to be on LVM you need an initramfs. / on raid (with custom kernel) or plain partition works without one. I already know that, thanks, but it still doesnât make your point. Just because you have some religious taboo against initramfs doesnât make it an invalid solution. Go back and look at what Goswin wrote in the first place: As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. It sounds like he feels that having an initramfs is very fragile the way Debian handles it now. If / is outside of lvm, then when the initramfs breaks, he can boot up without it and get to a place where he can regenerate an initramfs. That's not a religious taboo against initramfs. That's sensible troubleshooting behavior. --Ken Not quite. I don't need an initramfs at all. I boot with root=/dev/md0 using the raid autodetect of the kernel. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Mon, Jun 01, 2009 at 03:50:50PM +0200, Josselin Mouette wrote: Nowadays, you cannot use your system if you don’t use udev, so this is irrelevant. I'm writing this mail from a system without udev: $ cat /proc/version Linux version 2.6.26-1-vserver-686 (Debian 2.6.26-12) (wa...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Mon Dec 15 21:11:05 UTC 2008 $ dpkg -s udev | grep Status Status: unknown ok not-installed $ dpkg -s yaird | grep Status Status: install ok installed (Yes, I need to reboot ...) Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Jun 03, Carsten Hey cars...@debian.org wrote: I'm writing this mail from a system without udev: Yes, and nobody cares much. Many functions of modern systems require udev and more and more will with time. -- ciao, Marco signature.asc Description: Digital signature
Re: no deprecation of /usr as a standalone filesystem
On Wed, Jun 03, 2009 at 02:59:52PM +0200, Marco d'Itri wrote: On Jun 03, Carsten Hey cars...@debian.org wrote: On Mon, Jun 01, 2009 at 03:50:50PM +0200, Josselin Mouette wrote: Nowadays, you cannot use your system if you don’t use udev, so this is irrelevant. I'm writing this mail from a system without udev: Yes, and nobody cares much. Correct, it just shows that your argument is irrelevant because you can't use a system without udev is wrong, at least for lenny. Someone wrote a while ago: Debian ... will be easy to keep up-to-date with a 'upgrading' script in the base system which will allow complete integration of upgrade packages. How do you plan to ensure that upgrading from one stable release to the next is possible after deprecating /usr as a separate partition? Or do you plan to force all the systems using a separate /usr to be reinstalled whilst being upgraded to squeeze+n? Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org wrote: Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit : What has the initramfs got to do with this? For / to be on LVM you need an initramfs. / on raid (with custom kernel) or plain partition works without one. I already know that, thanks, but it still doesn’t make your point. Just because you have some religious taboo against initramfs doesn’t make it an invalid solution. Go back and look at what Goswin wrote in the first place: As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. It sounds like he feels that having an initramfs is very fragile the way Debian handles it now. If / is outside of lvm, then when the initramfs breaks, he can boot up without it and get to a place where he can regenerate an initramfs. That's not a religious taboo against initramfs. That's sensible troubleshooting behavior. --Ken -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit : What has the initramfs got to do with this? For / to be on LVM you need an initramfs. / on raid (with custom kernel) or plain partition works without one. I already know that, thanks, but it still doesn’t make your point. Just because you have some religious taboo against initramfs doesn’t make it an invalid solution. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: no deprecation of /usr as a standalone filesystem
* Josselin Mouette j...@debian.org [2009-06-02 10:53]: Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit : What has the initramfs got to do with this? For / to be on LVM you need an initramfs. / on raid (with custom kernel) or plain partition works without one. I already know that, thanks, but it still doesn’t make your point. Just because you have some religious taboo against initramfs doesn’t make it an invalid solution. Still that doesn't mean that the project should depricate support for a separate /usr for the sake of udev. If some want to use an initramfs less kernel let them have a functional system, same goes for those that prefere a udev less system. 2 cents Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Le mardi 02 juin 2009 à 11:22 +0200, Martin Wuertele a écrit : Still that doesn't mean that the project should depricate support for a separate /usr for the sake of udev. If some want to use an initramfs less kernel let them have a functional system, same goes for those that prefere a udev less system. What about those who want a system without libc? Did you think about them? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: no deprecation of /usr as a standalone filesystem
Marco d'Itri wrote: This is relevant for udev becase kernel events can trigger the execution of programs at the very beginning of the boot when only the root is mounted. While currently packages can and do easily implement workarounds for this situation (like waiting in a loop for the files in /usr they need to appear), in the future more complex modifications could be needed. For me it is not yet totally clear. You make easier some part of the problem, but it is seems to me that it is not a definitive solution: - there is still a close windows in initram, and possibility at early rc scripts. - /var is still not mounted, so programs could not write they status, nor log failures - care about security implication: user that triggers events before system is fully up (e.g. busy resources) - and I think other usual system assumption are not fulfilled, so maintainers should be trained on what they could assume on udev sequence. For these reasons, I think only few events (explicitly ack by maintainers) should be handled by early boot, and the rest run later (udev events are already asynchronous by definition). All things considered, I have no immediate plan to push for deprecating a standalone /usr. Eventually we could move the mounting of /usr earlier (maybe also in initrams), and support only few configurations (but we support a lot of different sources for root, so I think this is not a real limit). ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org writes: Le mardi 02 juin 2009 à 11:22 +0200, Martin Wuertele a écrit : Still that doesn't mean that the project should depricate support for a separate /usr for the sake of udev. If some want to use an initramfs less kernel let them have a functional system, same goes for those that prefere a udev less system. What about those who want a system without libc? Did you think about them? Yes, we have uclibc for them. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Sun, May 31, 2009 at 7:43 PM, Marco d'Itri m...@linux.it wrote: This is a summary of last month's thread about the feasibility of removing support for /usr on a standalone filesystem. The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. This is relevant for udev becase kernel events can trigger the execution of programs at the very beginning of the boot when only the root is mounted. That udev-triggered executables must not reside in /usr makes sense. And it makes sense to state that executables triggered from udev must be relatively low in the stack. Do I understand this right? The concern is about NetworkManager and similar stuff? IMHO the right fix is to decouple the bits of NM that receive the udev event from the high-in-the-stack, late-starting, a-zillion-deps NetworkManager. A small executable can catch the events and store them if the rest of the system is not there. IIRC, NM uses dbus which is also fairly late and laden. A simpler scheme would work. I don't meant to pick on NM, but it's a fairly well-known example that takes us from a udev event all the way to a desktop applet. Disk insertion applies too. My take is that software for the desktop that is mature and high quality must be extra careful in what it puts in udev scripts -- minimal deps and de-coupled operation from the desktop is a must. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Jun 02, Giacomo A. Catenazzi c...@debian.org wrote: - there is still a close windows in initram, and possibility at early rc scripts. No. - /var is still not mounted, so programs could not write they status, nor log failures So programs which have such requirements need to take care of waiting long enough. e.g. the ifupdown wrapper script waits for /dev/log to appear. - care about security implication: user that triggers events before system is fully up (e.g. busy resources) I see no security implications. - and I think other usual system assumption are not fulfilled, so maintainers should be trained on what they could assume on udev sequence. Maintainers who have doubts can ask for help here or by private mail. For these reasons, I think only few events (explicitly ack by maintainers) should be handled by early boot, and the rest run later (udev events are already asynchronous by definition). There is no need for this. -- ciao, Marco signature.asc Description: Digital signature
Re: no deprecation of /usr as a standalone filesystem
On Tue, 2009-06-02 at 12:54 +0200, Goswin von Brederlow wrote: Josselin Mouette j...@debian.org writes: What about those who want a system without libc? Did you think about them? Yes, we have uclibc for them. That's still libc. Would you take ucudev, uchal, and ucinitramfs to go with that? -- Gustavo Noronha k...@debian.org Debian Project -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Le dimanche 31 mai 2009 à 19:43 +0200, Marco d'Itri a écrit : All things considered, I have no immediate plan to push for deprecating a standalone /usr. Thanks for going back. However, if you think this debate is going to come back later, maybe we could ensure that we can remove this support later. This starts by encouraging people to use alternate solutions when possible, so that we don’t hit again the “I have setups that do this” issue in a few years. Discouraging the use of a separate /usr should start by removing the explicit option to mount a partition to /usr in the installer. You could still specify it by hand, but that would imply knowing what you’re doing. Some of the arguments mentioned in favour of a standalone /usr are: - NFS: but it's still unclear exactly how this is managed in practice (apparently it requires much handwaving), and there are alternatives like an unionfs or really stateless clients which are probably simpler and better Indeed, if you want /usr on NFS, you also want / on NFS. Maybe those interested in such setups could write a package that makes this easier, but everything is already here. - LVM and/or RAID: no real reason nowadays to not use these for the root - mounting it read only: some people obviously like this, but it's hardly something irreplaceable Again, if people want all of this for /usr, they also want it for /. Maybe the policy could make clear that any package not working with a read-only / is RC? - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop I decided to crypt only /home, and use symlinks for the few files in /etc which contain sensitive information, YMMV. I’m the only one who quoted it, and I already find this is a minor use case. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org writes: Le dimanche 31 mai 2009 à 19:43 +0200, Marco d'Itri a écrit : All things considered, I have no immediate plan to push for deprecating a standalone /usr. Thanks for going back. Seconded. Thanks also, Marco, for notifying us of this change in direction. However, if you think this debate is going to come back later, maybe we could ensure that we can remove this support later. This starts by encouraging people to use alternate solutions when possible, so that we don’t hit again the “I have setups that do this”issue in a few years. Why would a few years make the scenarios for separate-filesystem-/usr, already discussed here and acknowledged to be valid, suddenly worthy of deprecation? -- \ “Are you pondering what I'm pondering?” “Well, I think so, | `\Brain, but if Jimmy cracks corn, and no one cares, why does he | _o__) keep doing it?” —_Pinky and The Brain_ | Ben Finney pgpMxzyKy8v3H.pgp Description: PGP signature
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org writes: Le dimanche 31 mai 2009 à 19:43 +0200, Marco d'Itri a écrit : All things considered, I have no immediate plan to push for deprecating a standalone /usr. Thanks for going back. However, if you think this debate is going to come back later, maybe we could ensure that we can remove this support later. This starts by encouraging people to use alternate solutions when possible, so that we donât hit again the âI have setups that do thisâ issue in a few years. Discouraging the use of a separate /usr should start by removing the explicit option to mount a partition to /usr in the installer. You could still specify it by hand, but that would imply knowing what youâre doing. Some of the arguments mentioned in favour of a standalone /usr are: - NFS: but it's still unclear exactly how this is managed in practice (apparently it requires much handwaving), and there are alternatives like an unionfs or really stateless clients which are probably simpler and better Indeed, if you want /usr on NFS, you also want / on NFS. Maybe those interested in such setups could write a package that makes this easier, but everything is already here. - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. - mounting it read only: some people obviously like this, but it's hardly something irreplaceable Again, if people want all of this for /usr, they also want it for /. Maybe the policy could make clear that any package not working with a read-only / is RC? You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop I decided to crypt only /home, and use symlinks for the few files in /etc which contain sensitive information, YMMV. Iâm the only one who quoted it, and I already find this is a minor use case. Count me there too. Crypting /usr on a laptop just wastes performance and cpu which spells into real battery life. Although ecryptfs is probably a even better alternative. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote: Josselin Mouette j...@debian.org writes: - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. You meant /boot right ? You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. What's the purposes of mounting /usr nodev as all directories there are owned by root (or at least should be) ? - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop I decided to crypt only /home, and use symlinks for the few files in /etc which contain sensitive information, YMMV. Iâm the only one who quoted it, and I already find this is a minor use case. Count me there too. Crypting /usr on a laptop just wastes performance and cpu which spells into real battery life. Although ecryptfs is probably a even better alternative. Give me numbers please, crypting /usr in my experience wastes little amount of CPU given that the in-ram cache is _not_ encrypted, so as long you don't hit the disk, it costs almost nothing. And as soon as you hit the disk, I'm told that the disk consumptions in nowadays hardware wins over the CPU one from decryption. (I don't count encryption as you usually very seldomly _write_ to /usr except when you upgrade or install packages). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Le lundi 01 juin 2009 à 13:11 +0200, Goswin von Brederlow a écrit : As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. What has the initramfs got to do with this? You can not mount / nodev if you don't use udev. But you /usr you can. Nowadays, you cannot use your system if you don’t use udev, so this is irrelevant. Count me there too. Crypting /usr on a laptop just wastes performance and cpu which spells into real battery life. Please bring up figures; the amount of CPU used on a modern system is negligible, and the CPU is woken up anyway during IOs. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org writes: Le lundi 01 juin 2009 à 13:11 +0200, Goswin von Brederlow a écrit : As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. What has the initramfs got to do with this? For / to be on LVM you need an initramfs. / on raid (with custom kernel) or plain partition works without one. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote: Josselin Mouette j...@debian.org writes: - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. You meant /boot right ? No, /. Where /boot is has no effect on wether you need an initrd or not. That only interests the bootloader. You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. What's the purposes of mounting /usr nodev as all directories there are owned by root (or at least should be) ? Only allow what is neccessary. That way when accidentally some device node lands in /usr it still can't be abused. For example someone could sneak in a package into Debian that contains crw-rw-rw- 1 root kmem 1, 1 May 30 15:55 /usr/lib/rootkit/mem crw-rw-rw- 1 root kmem 1, 2 May 30 15:55 /usr/lib/rootkit/kmem - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop I decided to crypt only /home, and use symlinks for the few files in /etc which contain sensitive information, YMMV. Iâm the only one who quoted it, and I already find this is a minor use case. Count me there too. Crypting /usr on a laptop just wastes performance and cpu which spells into real battery life. Although ecryptfs is probably a even better alternative. Give me numbers please, crypting /usr in my experience wastes little amount of CPU given that the in-ram cache is _not_ encrypted, so as long you don't hit the disk, it costs almost nothing. Agreed. If it is cached it doesn't matter. IF. Most peoples /usr partition is by far larger than available ram not to mention only a part of that is used for cache. My old laptop only had 128MB ram. Forget about caching there. And as soon as you hit the disk, I'm told that the disk consumptions in nowadays hardware wins over the CPU one from decryption. (I don't count encryption as you usually very seldomly _write_ to /usr except when you upgrade or install packages). Cpu frequency scalled up all the way in both cases for the test: r...@frosties:~# time dd if=/dev/sdc of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 46.6188 s, 92.1 MB/s dd if=/dev/sdc of=/dev/null bs=1M count=4096 0.01s user 8.35s system 17% cpu 46.737 total r...@frosties:~# time dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 56.5635 s, 75.9 MB/s dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 0.02s user 8.66s system 15% cpu 56.806 total Despite that it says only 15% system is used in the case of sdc-crypt all the remaining cpu power is used up by: 2651 root -5 00 R 78.7 0.0 1:00.28 kcryptd Those 78% means that the cpu goes into full speed. The voltage and frequency is increased. The cpu fan spins up to a higher setting. The time spend in kcryptd is also stolen from e.g. gcc or ld. Compiling takes longer, esspecially the first time. The CPU stays in full speed for longer eating more power. For me the takes longer part is actually more important. That even holds when you are not running on battery. I don't have numbers on the battery life as I never compared the time with and without dm-crypt. Feel free to time it yourself. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Mon, Jun 01, 2009 at 05:13:16PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote: Josselin Mouette j...@debian.org writes: - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. You meant /boot right ? No, /. Where /boot is has no effect on wether you need an initrd or not. That only interests the bootloader. Huh, I completely fail to see why not having / on LVM is a matter of importance. You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. What's the purposes of mounting /usr nodev as all directories there are owned by root (or at least should be) ? Only allow what is neccessary. That way when accidentally some device node lands in /usr it still can't be abused. For example someone could sneak in a package into Debian that contains crw-rw-rw- 1 root kmem 1, 1 May 30 15:55 /usr/lib/rootkit/mem crw-rw-rw- 1 root kmem 1, 2 May 30 15:55 /usr/lib/rootkit/kmem Think again, if I do such a package, I would obviously check with some kind of trivial perl programm if the device containing /usr/lib/rootkit is mounted with nodev, would use mount -o remount,dev on the problematic mount point in the preinst, let the unpacking happen, and remount properly in the postinst. If you're root, nodev is useless. That's exactly why I mentioned the fact that every single path in /usr is supposed to be root:root, IOW to create a device there you *have* to be root, and nodev won't stop you. Cpu frequency scalled up all the way in both cases for the test: r...@frosties:~# time dd if=/dev/sdc of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 46.6188 s, 92.1 MB/s dd if=/dev/sdc of=/dev/null bs=1M count=4096 0.01s user 8.35s system 17% cpu 46.737 total r...@frosties:~# time dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 56.5635 s, 75.9 MB/s dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 0.02s user 8.66s system 15% cpu 56.806 total Despite that it says only 15% system is used in the case of sdc-crypt all the remaining cpu power is used up by: 2651 root -5 00 R 78.7 0.0 1:00.28 kcryptd Those 78% means that the cpu goes into full speed. The voltage and frequency is increased. The cpu fan spins up to a higher setting. The time spend in kcryptd is also stolen from e.g. gcc or ld. Compiling takes longer, esspecially the first time. The CPU stays in full speed for longer eating more power. For me the takes longer part is actually more important. That even holds when you are not running on battery. I don't have numbers on the battery life as I never compared the time with and without dm-crypt. Feel free to time it yourself. The point is, unless you're loading pretty large stuff (IOW larger than a few hundreds of kilobytes, say files of size 512k) your figures are wrong, because for small stuff (and it's most of what people are reading from /usr) spining the hard disk is way slower than decrypting the data. Raw performance is actually very far from what actually happens in real life. And if you really care about those extra bits of performance, then what I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted, and to encrypt /var, /srv and /home, with the option to let /home be a bind mount of /srv/home or similar if you don't want 3 partitions. IOW even for this kind of optimization, you have a trivial workaround -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Mon, 2009-06-01 at 19:51 +1000, Ben Finney wrote:
Josselin Mouette j...@debian.org writes:
Le dimanche 31 mai 2009 à 19:43 +0200, Marco d'Itri a écrit :
All things considered, I have no immediate plan to push for
deprecating a standalone /usr.
Thanks for going back.
Seconded. Thanks also, Marco, for notifying us of this change in
direction.
I found that Marco's summary was partial (i.e not a summary of the
situation but his answer to FAQ).
However, if you think this debate is going to come back later, maybe
we could ensure that we can remove this support later. This starts by
encouraging people to use alternate solutions when possible, so that
we don’t hit again the “I have setups that do this”issue in a few
years.
Why would a few years make the scenarios for separate-filesystem-/usr,
already discussed here and acknowledged to be valid, suddenly worthy of
deprecation?
Why?
[answering Marco's list]
- Because Debian could state now that standalone /usr won't be
supported in Squeeze+n, modifying D-I (see other posts).
- Because old hardware will be 686 + ?GB disk rather than
486 + ?MB disk...
- Because SSD disk will be really cheap and reliable (???)
- Because backup software will be even better ;)
- Because D-I might install LVM system by default, making it easy to
resume from / is full
- Because all architecture could have a boot-loader that support
LVM + ${ENCRYPTED_FS}
- Because SELinux could be enabled by default, reducing the need for
read-only / filesystem
etc.
Franklin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Mon, 01 Jun 2009, Pierre Habouzit wrote: Think again, if I do such a package, I would obviously check with some kind of trivial perl programm if the device containing /usr/lib/rootkit is mounted with nodev, would use mount -o remount,dev on the problematic mount point in the preinst, let the unpacking happen, and remount properly in the postinst. AFAIK, nodev blocks device nodes from _WORKING_ as well. Anyway, one would need to just remount it dev as root to exploit. Of course, when you have el-crap-o pathbased security plus something locking down remounts, the above is an attack vector that separate /usr could close. Not something someone using SE Linux would need to care about, though. And if you really care about those extra bits of performance, then what I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted, And now you need /etc as a separate partition, which is a lot worse to pull off than /usr as a separate partition... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Mon, Jun 01, 2009 at 03:08:02PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 01 Jun 2009, Pierre Habouzit wrote: Think again, if I do such a package, I would obviously check with some kind of trivial perl programm if the device containing /usr/lib/rootkit is mounted with nodev, would use mount -o remount,dev on the problematic mount point in the preinst, let the unpacking happen, and remount properly in the postinst. AFAIK, nodev blocks device nodes from _WORKING_ as well. Anyway, one would need to just remount it dev as root to exploit. Of course, when you have el-crap-o pathbased security plus something locking down remounts, the above is an attack vector that separate /usr could close. Not something someone using SE Linux would need to care about, though. And if you really care about those extra bits of performance, then what I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted, And now you need /etc as a separate partition, which is a lot worse to pull off than /usr as a separate partition... cat /etc/fstab /srv/localhost/etc / auto bind ^D mount /etc done -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 03:08:02PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 01 Jun 2009, Pierre Habouzit wrote: Think again, if I do such a package, I would obviously check with some kind of trivial perl programm if the device containing /usr/lib/rootkit is mounted with nodev, would use mount -o remount,dev on the problematic mount point in the preinst, let the unpacking happen, and remount properly in the postinst. AFAIK, nodev blocks device nodes from _WORKING_ as well. Anyway, one would need to just remount it dev as root to exploit. Of course, when you have el-crap-o pathbased security plus something locking down remounts, the above is an attack vector that separate /usr could close. Not something someone using SE Linux would need to care about, though. And if you really care about those extra bits of performance, then what I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted, And now you need /etc as a separate partition, which is a lot worse to pull off than /usr as a separate partition... cat /etc/fstab /srv/localhost/etc / auto bind ^D mount /etc done And if that fails to mount: go await, you don't exist. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 05:13:16PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote: Josselin Mouette j...@debian.org writes: - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. You meant /boot right ? No, /. Where /boot is has no effect on wether you need an initrd or not. That only interests the bootloader. Huh, I completely fail to see why not having / on LVM is a matter of importance. Because / on LVM requires an initramfs to start lvm. You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. What's the purposes of mounting /usr nodev as all directories there are owned by root (or at least should be) ? Only allow what is neccessary. That way when accidentally some device node lands in /usr it still can't be abused. For example someone could sneak in a package into Debian that contains crw-rw-rw- 1 root kmem 1, 1 May 30 15:55 /usr/lib/rootkit/mem crw-rw-rw- 1 root kmem 1, 2 May 30 15:55 /usr/lib/rootkit/kmem Think again, if I do such a package, I would obviously check with some kind of trivial perl programm if the device containing /usr/lib/rootkit is mounted with nodev, would use mount -o remount,dev on the problematic mount point in the preinst, let the unpacking happen, and remount properly in the postinst. If you're root, nodev is useless. That's exactly why I mentioned the fact that every single path in /usr is supposed to be root:root, IOW to create a device there you *have* to be root, and nodev won't stop you. Nodev prevents the device node from working. Doesn't phase mknod at all. That means while you can still create device nodes and give them any permissions you like nobody can use them. Cpu frequency scalled up all the way in both cases for the test: r...@frosties:~# time dd if=/dev/sdc of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 46.6188 s, 92.1 MB/s dd if=/dev/sdc of=/dev/null bs=1M count=4096 0.01s user 8.35s system 17% cpu 46.737 total r...@frosties:~# time dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 56.5635 s, 75.9 MB/s dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 0.02s user 8.66s system 15% cpu 56.806 total Despite that it says only 15% system is used in the case of sdc-crypt all the remaining cpu power is used up by: 2651 root -5 00 R 78.7 0.0 1:00.28 kcryptd Those 78% means that the cpu goes into full speed. The voltage and frequency is increased. The cpu fan spins up to a higher setting. The time spend in kcryptd is also stolen from e.g. gcc or ld. Compiling takes longer, esspecially the first time. The CPU stays in full speed for longer eating more power. For me the takes longer part is actually more important. That even holds when you are not running on battery. I don't have numbers on the battery life as I never compared the time with and without dm-crypt. Feel free to time it yourself. The point is, unless you're loading pretty large stuff (IOW larger than a few hundreds of kilobytes, say files of size 512k) your figures are wrong, because for small stuff (and it's most of what people are reading from /usr) spining the hard disk is way slower than decrypting the data. Have you looked at the size of kde or gnome in the last, oh say, 5 years? And you are wrong even for small files, or should I say esspecially? On small files you seek, you read a chunk of encrypted data, you decrypt it, you process it and only then the next chunk is requested. With random access things like the disks read-ahead won't decrypt the next block already while you process the current one. Raw performance is actually very far from what actually happens in real life. Sure, real life is usualy an order slower. And if you really care about those extra bits of performance, then what I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted, and to encrypt /var, /srv and /home, with the option to let /home be a bind mount of /srv/home or similar if you don't want 3 partitions. IOW even for this kind of optimization, you have a trivial workaround And let anyone stealing my laptop steal my data too? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
no deprecation of /usr as a standalone filesystem
This is a summary of last month's thread about the feasibility of removing support for /usr on a standalone filesystem. The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. This is relevant for udev becase kernel events can trigger the execution of programs at the very beginning of the boot when only the root is mounted. While currently packages can and do easily implement workarounds for this situation (like waiting in a loop for the files in /usr they need to appear), in the future more complex modifications could be needed. All things considered, I have no immediate plan to push for deprecating a standalone /usr. Some of the arguments mentioned in favour of a standalone /usr are: - NFS: but it's still unclear exactly how this is managed in practice (apparently it requires much handwaving), and there are alternatives like an unionfs or really stateless clients which are probably simpler and better - junk hardware: please deal with the progress. keeping around forever old hardware because it still works is not green computing - backups: I know for a fact that decent backup software exists - LVM and/or RAID: no real reason nowadays to not use these for the root - mounting it read only: some people obviously like this, but it's hardly something irreplaceable - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop I decided to crypt only /home, and use symlinks for the few files in /etc which contain sensitive information, YMMV. -- ciao, Marco signature.asc Description: Digital signature
Re: no deprecation of /usr as a standalone filesystem
On Sun, May 31, 2009 at 07:43:00PM +0200, Marco d'Itri wrote: This is a summary of last month's thread about the feasibility of removing support for /usr on a standalone filesystem. The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. I spoke with Scott James Remnant at UDS about this, and he clarified that Ubuntu does not support /usr *on NFS*; which is accurate, since there are significant changes that need to be made to the out-of-the-box configuration to get this to work. But Ubuntu *does* support /usr on a separate filesystem. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
