Re: [Feature Suggestion] UsrMove continued
On Wed, Oct 10, 2012 at 03:04:51PM +0200, Michal Schmidt wrote: Dne 10.10.2012 14:25, David Howells napsal(a): Actually, the UsrMove has mucked up at least one way of doing things: we have/had RHEL customer(s) who kept /usr on AFS and were able to boot just using the stuff in /bin and /sbin. This is no longer a viable option with Fedora, and presumably RHEL-7. The initramfs should contain everything necessary to mount / and /usr. Isn't there a dracut module for AFS support? If not, it should be added. Has a bug been reported? As far as I know initrd doesn't provide sane environment for troubleshooting possible issues. Additionally / can be modified by standard fs tools quite surprsingly. ;) It isn't case of initrd. Dracut seems to be good solution for this case unless something breaks. -- Regards, Marian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
Chris Adams wrote: Once upon a time, Seth Vidal skvi...@fedoraproject.org said: Not every decision a distribution makes is a good one, lets not get caught up believing that we cannot make mistakes. UsrMove was a mistake. End of discussion. Let's go back. I agree. The additional churn would be another one-time pain, but then the Band-Aid™ would be ripped off and we'd be done. Unfortunately, it's much harder to undo UsrMove than it was to do it: UsrMove just required merging some pairs of directories, unmerging them is much trickier. That's yet another reason why UsrMove is broken, it is almost impossible to revert. We've really painted us into a corner. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
David Howells wrote: Actually, the UsrMove has mucked up at least one way of doing things: we have/had RHEL customer(s) who kept /usr on AFS and were able to boot just using the stuff in /bin and /sbin. This is no longer a viable option with Fedora, and presumably RHEL-7. Actually, systemd had already refused to support this setup before UsrMove, and this was cited as one of the reasons for doing UsrMove (ensuring the draconian way that users won't even try using that setup). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Qua, 2012-10-10 at 13:11 +0300, Serge wrote: Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. Don't see why ? ll / lib - usr/lib lib64 - usr/lib64 sbin - usr/sbin bin - usr/bin What is the difference of /lib and /usr/lib ? What I see in Debian is a big confusion for example, with perl: they have /usr/lib/perl/ /usr/lib/perl5/ /usr/lib/perl5/auto /usr/share/perl/ /usr/share/perl5/ And I have some modules in double and in different versions, which is a mess. If you have just one directory you avoid double version of same software. Regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
2012/10/10 David Howells wrote: The contents of /dev vary depending on what hardware the computer has available - which may change in real time - so it cannot be shared, so why move it? Ah, no, /dev was moved not because of sharing. It's just original UsrMove among other benefits has the line: Simpler and cleaner overall file system layout, with full compatibility. I was just trying to actually do that. The best implementation I could come up with is: /os-- OS, kernel-space /usr -- user-space, shareable, possibly read-only, /var -- variable system data, read-write, non-shareable /home -- variable user data, read-write, shareable And nothing else. Looks very simple, clean, easy to understand. That was the point for UsrMove. Or at least the UsrMove page says so... You would _have_ to have symlinks at /dev and /proc - so moving these gains you nothing. Except simple and clean file system layout. Does it have any drawbacks? I could not notice any changes in speed, I see no difference in functionality. It works same, but looks better. :) And some years later we may drop those symlinks, as well as /lib, /bin... ... But an eyecandy kernel module can hide those symlinks, so user would see a nice simple layout right now, and not in 10 years. Ugh. Don't go there. Really don't. That's for userspace to deal with - just like hiding files whose name begins with a .. Well, that was just an idea: show everything for `root` (UID=0), but hide for the rest, so users could see the beauty. :) Which does not prevent you from leaving /dev and /proc where they are. Well, maybe you're right. I have just listed all the ideas together, trying to look as forward as possible. We can filter the best of them and postpone/throw out the others. That's what the initial email was written for. Actually, the UsrMove has mucked up at least one way of doing things I agree that UsrMove is not in a good shape now. So it should be either backed out, or moved forward and fixed. That's what I'm trying to do. we have/had RHEL customer(s) who kept /usr on AFS and were able to boot just using the stuff in /bin and /sbin. This is no longer a viable option with Fedora, and presumably RHEL-7. In my case the goal is to mount /usr using stuff in initramfs. -- Serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
2012/10/11 Adam Williamson wrote: A proposal to change the filesystem that was synchronized with and planned to continue to be identical to (or at least fully compatible with) how it's done in Android and Solaris, with the participation of Google and Oracle, would be a more interesting proposal Why doing identical if we can do it better? Solaris implemented UsrMove (or rather /sbin-move in their case) in a very weird way. Their initramfs has non-empty /usr directory which contains the files from former /sbin and /lib, necessary to mount /usr. Real /usr is just mounted on top of them hiding the old /usr content. But, I guess you already knew that, since even original UsrMove page mentions Minimize difference to other Unixes, such as Solaris. I remember someone had even blogged about that [1]. Androids implemented it differently, they also use initramfs for the root filesystem layout. But they do not reuse existing directories, instead they created a set of new directories (/system, /data, /cache...) and then put symlinks there (i.e. /etc - /system/etc). I tried to make it better. To minimize changes I reused existing/known directories so that their names still matched their content. Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. As was already said, that change also had clear concrete benefits; the incompatibility was acknowledged as a drawback, but the benefit was traded off against the drawback, and it won. Your proposal seems short on clear concrete benefits Actually my proposal is based on same benefits, it just adds more (simpler diskless NFS stations, multiple OSes on same partition, etc). It was aiming for a simple layout, and I made it as simple as I could. It was trying to separate different resources, and I separated them, grouping same resources into same directories. And so on. You can compare initial email with UsrMove wiki page. Or are there other UsrMove benefits that were not listed on a wiki page? [1] https://plus.google.com/u/0/115547683951727699051/posts/DiGcrjDaKEb -- Serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
2012/10/9 Jochen Schmitt wrote: I want to disagree with your suggestion. /root is the home directory of the superuser and should not be placed on a network device in opposite of the home directories of the ordinary users. The user root should be able to logon without a network connection to do any rescue work on the system. This argument would work for original UsrMove feature. But it's already done. Right now user `root` cannot login without /usr being mounted, because it needs at least bash, which is now /usr/bin/bash. Moving /root to /usr is just consistent continuation of implemented UsrMove. I want to consider, that /etc should be mounted on a writeable partition in opposite of /usr to allow changes without remounting. Probably you're right, but I can't think of any real-world examples where it would be needed. Can you name some? My line of reasoning was: if you're managing a set of machines with shared /usr you always want /etc to be shared too. It's a pain for admin to install/update some software and then run across all the machines to set up new /etc files everywhere. And as long as /etc is also shared among multiple machines it should be read-only as well as /usr. This is needed at least as a security measure, so you could be sure that some bug on one machine won't break everything else. your test case didn't hit your suggestion of remove the /etc directory. It did. :) Check the following line closely: # mv -f /root /etc /usr/; ln -s usr/root usr/etc / It actually does not hit the /tmp case (mount-bind is used instead of symlink). But that's solely because of systemd becoming extremely unhappy when /tmp is a symlink. -- Serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
2012/10/9 tim.lauridsen wrote: So you make your system incompatible with every other Linux distro out there, and with all existing documentation, but to what end? Tidyness? Tidyness, simplicity, new features... Incompatible with older, but compatible with newer distros. That's close to what Solaris does on its livecd and really close to what Android does on mobile phones. Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. +1 to Richard, I really don't see the purpose, why does it matter that number of dirs in /. I don't know why, but some people actually like when there're fewer subdirectories in a directory. Lot of apps will break if you move /proc or /dev Sure. And many apps would break if you move /bin to /usr/bin. But still, you did that? ;) and if you replace them with symlink in the next 10 years you still have the same number of dirs under /, you have even more because you have added some new ones. That's a compatibility tradeoff. But an eyecandy kernel module can hide those symlinks, so user would see a nice simple layout right now, and not in 10 years. I can understand you want to merge dirs there have the same function /bin - /usr/bin, but this has no benefits at all. Quite the contrary. If you compare it with the original UsrMove page you will see that it had same reasons, same Benefits and User Experience, but no final goal. Original UsrMove was looking like separate /usr is partially broken, let's break it completely. It officially declared that we don't know what files should be put to /bin or /usr/bin, but it brought no new features. While this one (besides creating even more Simpler and cleaner file system layout) has a goal: making explicit root filesystem optional (i.e. so small and simple that it could be replaced with initramfs). Which gives lots of new features, like simple diskless NFS stations, multiple distros on same partition, easier lightweight containers... I could understand if arguments against it were suggested before UsrMove implementation. But it's already there. There're already symlinks to /bin, /lib, /sbin. Root user already cannot login without /usr being mounted. And similar selinux issues were already taken care of. Most of the work is already done. It's not a new suggestion, it's the same UsrMove, but now it can bring some new features. -- Serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Wed, 10 Oct 2012 13:11:12 +0300, Serge wrote: Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. The fact that we've made one useless and harmful mistake doesn't mean that we should repeat it all the time. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Wed, Oct 10, 2012 at 10:24:54AM +, Matěj Cepl wrote: On Wed, 10 Oct 2012 13:11:12 +0300, Serge wrote: Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. The fact that we've made one useless and harmful mistake doesn't mean that we should repeat it all the time. +1. Only this week and last I had to deal with two small bugs caused by UsrMove. It's a never-ending source of issues, and needlessly incompatible with Debian. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
Dne 10.10.2012 14:25, David Howells napsal(a): Actually, the UsrMove has mucked up at least one way of doing things: we have/had RHEL customer(s) who kept /usr on AFS and were able to boot just using the stuff in /bin and /sbin. This is no longer a viable option with Fedora, and presumably RHEL-7. The initramfs should contain everything necessary to mount / and /usr. Isn't there a dracut module for AFS support? If not, it should be added. Has a bug been reported? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Wed, 10 Oct 2012, Matěj Cepl wrote: On Wed, 10 Oct 2012 13:11:12 +0300, Serge wrote: Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. The fact that we've made one useless and harmful mistake doesn't mean that we should repeat it all the time. I cannot agree enough. Just b/c we've blundered down a bad route doesn't mean you cannot turn back. Instead of chiseling our way back, let's just revert and go. Not every decision a distribution makes is a good one, lets not get caught up believing that we cannot make mistakes. UsrMove was a mistake. End of discussion. Let's go back. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Wed, Oct 10, 2012 at 9:45 AM, Seth Vidal skvi...@fedoraproject.orgwrote: I cannot agree enough. Just b/c we've blundered down a bad route doesn't mean you cannot turn back. Instead of chiseling our way back, let's just revert and go. Not every decision a distribution makes is a good one, lets not get caught up believing that we cannot make mistakes. UsrMove was a mistake. End of discussion. Let's go back. However, whether you believe this or not, UsrMove was at least an attempt to solve an actual potential problem- perceived redundancy in /bin and /lib and /usr/bin and /usr/lib. I still don't see what problem this proposal would solve. To me it feels like a solution without a problem solely for the sake of tidiness in /. Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
Once upon a time, Seth Vidal skvi...@fedoraproject.org said: Not every decision a distribution makes is a good one, lets not get caught up believing that we cannot make mistakes. UsrMove was a mistake. End of discussion. Let's go back. I agree. The additional churn would be another one-time pain, but then the Band-Aid™ would be ripped off and we'd be done. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Wed, Oct 10, 2012 at 01:11:12PM +0300, Serge wrote: 2012/10/9 tim.lauridsen wrote: +1 to Richard, I really don't see the purpose, why does it matter that number of dirs in /. I don't know why, but some people actually like when there're fewer subdirectories in a directory. Then I suggest that you start with /usr/share/doc. Also, define fewer. Is 16 too much? (apparently yes) What about 8? 4? 2? (o, the good old binary tree...) Btw, why is this a problem with directories and not with files too? UsrMove _added_ lots of files to /usr/bin and /usr/sbin, yet you seem to approve of it... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Wed, 2012-10-10 at 13:11 +0300, Serge wrote: 2012/10/9 tim.lauridsen wrote: So you make your system incompatible with every other Linux distro out there, and with all existing documentation, but to what end? Tidyness? Tidyness, simplicity, new features... Incompatible with older, but compatible with newer distros. That's close to what Solaris does on its livecd and really close to what Android does on mobile phones. As my favourite American folk saying goes: 'close' only counts in horseshoes and hand grenades. :) A proposal to change the filesystem that was synchronized with and planned to continue to be identical to (or at least fully compatible with) how it's done in Android and Solaris, with the participation of Google and Oracle, would be a more interesting proposal than 'let's just do something kind of like what they're doing, but not the same, on our own, not co-ordinating with them'. It might still face a lot of resistance, but it'd be _more_ interesting. Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. As was already said, that change also had clear concrete benefits; the incompatibility was acknowledged as a drawback, but the benefit was traded off against the drawback, and it won. Your proposal seems short on clear concrete benefits, but still has all the drawback. Other distros are now adopting /usr move, which is kind of what we expected to happen, so that drawback will go away. They'd be less likely to adopt a change like this, made for the sake of 'neatness'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On 10/11/2012 02:44 AM, Adam Williamson wrote: On Wed, 2012-10-10 at 13:11 +0300, Serge wrote: 2012/10/9 tim.lauridsen wrote: So you make your system incompatible with every other Linux distro out there, and with all existing documentation, but to what end? Tidyness? Tidyness, simplicity, new features... Incompatible with older, but compatible with newer distros. That's close to what Solaris does on its livecd and really close to what Android does on mobile phones. As my favourite American folk saying goes: 'close' only counts in horseshoes and hand grenades. :) A proposal to change the filesystem that was synchronized with and planned to continue to be identical to (or at least fully compatible with) how it's done in Android and Solaris, with the participation of Google and Oracle, would be a more interesting proposal than 'let's just do something kind of like what they're doing, but not the same, on our own, not co-ordinating with them'. It might still face a lot of resistance, but it'd be _more_ interesting. Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. As was already said, that change also had clear concrete benefits; the incompatibility was acknowledged as a drawback, but the benefit was traded off against the drawback, and it won. Really? Don't you think the answers on in this thread speak a different language. Your proposal seems short on clear concrete benefits, but still has all the drawback. Other distros are now adopting /usr move, which is kind of what we expected to happen, so that drawback will go away. They'd be less likely to adopt a change like this, made for the sake of 'neatness'. Openly said, I believe this is just an imitation cult - These other distros will likely go through the same learning curves as Fedora and come to the same conclusions as Fedora. UsrMove being a mistake, which should be reverted. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Tue, Oct 09, 2012 at 02:18:10AM +0300, Serge wrote: * /root was initially on a root partition because 'root' user should be able to login even when all other FS (including /usr) are not mounted. Since now it can't do anything without /usr anyway, /root dir don't have to be in /. I want to disagree with your suggestion. /root is the home directory of the superuser and should not be placed on a network device in opposite of the home directories of the ordinary users. The user root should be able to logon without a network connection to do any rescue work on the system. * /etc contains data and configs for userspace programs, it's useless without them, and don't have to be separated. After all GNU autotools have never been aware of such split in the first place. I want to consider, that /etc should be mounted on a writeable partition in opposite of /usr to allow changes without remounting. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Tue, Oct 09, 2012 at 02:18:10AM +0300, Serge wrote: Obviously this won't go in F18. But it mostly works, you can test it: 0. Get Fedora17 LiveCD 1. Boot it with additional kernel params: selinux=0 systemd.log_level=debug systemd.log_target=console init=/bin/bash 2. When you get the shell: # mkdir /os /os/proc /os/sys /os/dev # mount --move /proc /os/proc; rm -rf /proc; ln -s os/proc / # mount --move /sys /os/sys; rm -rf /sys; ln -s os/sys / # mount --move /dev /os/dev; rm -rf /dev; ln -s os/dev / # mv /boot /os/; ln -s os/boot / # rm -f /var/run; mkdir /var/run # mount -n --move /run /var/run; rm -rf /run; ln -s var/run / # mv -f /root /etc /usr/; ln -s usr/root usr/etc / # mount --bind /var/tmp /tmp # exec /sbin/init and it should work as usual. your test case didn't hit your suggestion of remove the /etc directory. I think you have put any more love to workout your suggestion on this topic. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
So you make your system incompatible with every other Linux distro out there, and with all existing documentation, but to what end? Tidyness? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Tue, Oct 9, 2012 at 9:40 AM, Richard W.M. Jones rjo...@redhat.comwrote: So you make your system incompatible with every other Linux distro out there, and with all existing documentation, but to what end? Tidyness? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel +1 to Richard, I really don't see the purpose, why does it matter that number of dirs in /. Lot of apps will break if you move /proc or /dev, and if you replace them with symlink in the next 10 years you still have the same number of dirs under /, you have even more because you have added some new ones. I can understand you want to merge dirs there have the same function /bin - /usr/bin, but this has no benefits at all. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On 10/09/2012 10:13 AM, tim.laurid...@gmail.com wrote: I can understand you want to merge dirs there have the same function /bin - /usr/bin, but this has no benefits at all. I am not sure if this has no benefits whatsoever, but I do agree that if you want to keep the compatibility (which you IMHO should), you need to keep the symlinks, indeed making the tidiness argument invalid. Compatibility between distros is also a big thing for me, because quite often I look for solutions to Fedora problems in Arch or Debian forums, and I do find them. So +1 to status quo. TR -- FAS, IRC nick tradej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Tue, Oct 9, 2012 at 4:13 AM, tim.laurid...@gmail.com tim.laurid...@gmail.com wrote: +1 to Richard, I really don't see the purpose, why does it matter that number of dirs in /. Lot of apps will break if you move /proc or /dev, and if you replace them with symlink in the next 10 years you still have the same number of dirs under /, you have even more because you have added some new ones. I can understand you want to merge dirs there have the same function /bin - /usr/bin, but this has no benefits at all. Symlinks also dramatically complicate SELinux policies, since you then have to allow read_lnk_files in addition to plain filesystem access. Allowing read_lnk_files is undesirable, as there is a number of security vulnerabilities that make use of symbolic links, so this will be a net negative to the security of the system. Regards, -- Konstantin Ryabitsev LinuxFoundation.org Montréal, Québec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
* /root was initially on a root partition because 'root' user should be able to login even when all other FS (including /usr) are not mounted. Since now it can't do anything without /usr anyway, /root dir don't have to be in /. As an example of why this is a bad idea... I have a file server that, until recently, had /usr on an LVM so it could be dynamically resized. Sometimes, the machine would unexpectedly reboot and be unable to bring the VGs up. The repair scripts were in ~root. I would boot the rescue disk, ro-mount /, and run the repair scripts. If ~root were in the VG somewhere I would not have been able to repair the system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2012 04:01 PM, Konstantin Ryabitsev wrote: On Tue, Oct 9, 2012 at 4:13 AM, tim.laurid...@gmail.com tim.laurid...@gmail.com wrote: +1 to Richard, I really don't see the purpose, why does it matter that number of dirs in /. Lot of apps will break if you move /proc or /dev, and if you replace them with symlink in the next 10 years you still have the same number of dirs under /, you have even more because you have added some new ones. I can understand you want to merge dirs there have the same function /bin - /usr/bin, but this has no benefits at all. Symlinks also dramatically complicate SELinux policies, since you then have to allow read_lnk_files in addition to plain filesystem access. Allowing read_lnk_files is undesirable, as there is a number of security vulnerabilities that make use of symbolic links, so this will be a net negative to the security of the system. Regards, -- Konstantin Ryabitsev LinuxFoundation.org Montréal, Québec I think drastic might be an exagerations. In this case most apps will be just reading links to var_t, usr_t and other system defaults, which almost all domains can currently do. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB0b2sACgkQrlYvE4MpobNwPgCdHBMP4YoVOfSDoKNlGVCYTYR8 /04An0Lw69Mp5BI+ArequUsc6c8PJB/Y =JLRH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
