Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On 04/02/2012 15:58, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk - it doesn't support O_DIRECT - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. 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 I really need to remember to send with the right user identity for this list. resend of my message since its going to bounce That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On 04/02/2012 16:06, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 04:04:23PM -0400, David Quigley wrote: On 04/02/2012 15:58, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk - it doesn't support O_DIRECT - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. 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 I really need to remember to send with the right user identity for this list. resend of my message since its going to bounce That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes. That's not what I said. I said that relatively recent kernels (up to the middle of last year) didn't support system.*, and tmpfs doesn't support user.* at all AFAICT. 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 I wasn't contesting your statement of user.* and system.* I was just pointing out that tmpfs has supported SELinux labels for a very long time. Even well before Eric's patch last year that put generic xattr handlers in. So there should be no issue at all with SELinux labels on tmpfs even if you run older kernels. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On 03/16/2012 04:56, Matej Cepl wrote: On 15.3.2012 09:38, Tomasz Torcz wrote: Why and why just us? Good question, we deviate from upstream default: http://wiki.apache.org/httpd/DistrosDefaultLayout Do we have somebody to make the stupid item 3 go away? # If you're having issues with authorization and your permissions are # correct make sure that you try testing with SELinux turned off. Run # 'setenforce 0' and use 'chcon' to fix permissions. Run 'ls -alZ' to # view the current permissions.' SELinux first appeared in Fedora Core # 3, RHEL 4, and CentOS 4. httpd in Fedora/RHEL/CentOS works with SELinux just fine. Anything else are bugs, which need to be filed. Matěj Short of educating web server administrators about SELinux and the correct labels for web resources I'm not sure what else can be done. You don't want to use restorecond to make sure the directories are labeled properly because you could potentially use an improperly configured file upload capability to drop whatever pages you want onto the server and it would fixup the labels. Unfortunately education is the best option but not the easiest. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On 03/09/2012 08:42, Przemek Klosowski wrote: On 03/09/2012 01:43 AM, Adam Williamson wrote: On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: I'm not sure how useful 'time' is as a benchmark for file copies. Don't file transfers get cached and return to a console as 'complete' long before the data is ever written, sometimes? I'm pretty sure you sometimes hit the case where you copy 200MB to a USB stick, it returns to the console pretty fast, but the light on the stick is still flashing, and if you run 'sync', it sits there for quite a while before returning to the console, indicating the transfer wasn't really complete. So I'm not sure 'time'ing a 'cp' is an accurate test of actual final-write-to-device. That is true---but in that case, we could flush the disks. and then time the operation followed by another flush, i.e.: sync; time (cp ...; sync) I assume that the old-time Unix superstition of calling sync three times no longer applies :) Perhaps a dedicated disk benchmark like bonnie++ would be a better test, though. If you want to look seriously into file-system benchmarking I would suggest looking into the work done by the fsbench people at Stony Brook University's Filesystem and Storage Lab (FSL). There is a survey paper there for the last decade of FS benchmarks and their short commings and what should be addressed. http://www.fsl.cs.sunysb.edu/project-fsbench.html Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: phoronix benchmarks ext4 vs. btrfs
On 03/09/2012 11:00, Josef Bacik wrote: On Fri, Mar 9, 2012 at 10:11 AM, David Quigley seli...@davequigley.com wrote: On 03/09/2012 08:42, Przemek Klosowski wrote: On 03/09/2012 01:43 AM, Adam Williamson wrote: On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: I'm not sure how useful 'time' is as a benchmark for file copies. Don't file transfers get cached and return to a console as 'complete' long before the data is ever written, sometimes? I'm pretty sure you sometimes hit the case where you copy 200MB to a USB stick, it returns to the console pretty fast, but the light on the stick is still flashing, and if you run 'sync', it sits there for quite a while before returning to the console, indicating the transfer wasn't really complete. So I'm not sure 'time'ing a 'cp' is an accurate test of actual final-write-to-device. That is true---but in that case, we could flush the disks. and then time the operation followed by another flush, i.e.: sync; time (cp ...; sync) I assume that the old-time Unix superstition of calling sync three times no longer applies :) Perhaps a dedicated disk benchmark like bonnie++ would be a better test, though. If you want to look seriously into file-system benchmarking I would suggest looking into the work done by the fsbench people at Stony Brook University's Filesystem and Storage Lab (FSL). There is a survey paper there for the last decade of FS benchmarks and their short commings and what should be addressed. http://www.fsl.cs.sunysb.edu/project-fsbench.html fsbench is amazing, I also use fio and fs_mark to test various things. But these are artificial workloads! These numbers don't mean a damned thing to anybody, the only way you know if a fs is going to work for you is if you run your application on a couple of fses and figure out which one is faster for you! For example if you mostly compile kernels, btrfs is fastest. However if you mostly use a fs for your virt images, don't use btrfs! It's all a matter of workloads and no amount of benchmarking is going to be able to tell you if your pet workload is going to work well at all. The work that we file system developers do with benchmarking is to stress particular areas of our respective filesystems. For example, with Dave's tests he was testing our ability to scale as the amount of metadata gets ridiculously huge. He has exposed real problems that we are working on fixing. However these real problems are things that I imagine 99% of you will never run into, and therefore should not be what you use to base your decisions on. So let's try to remember that benchmarks mean next to nothing to real users, unless watching iozone output happens to be what you use your computer for. Thanks, Josef True fsbench can be used for micro benchmarking but if you read the paper on that page it also goes over the bechmarking suites that are supposed to provide real world workloads as well. Copying files isn't much more complex than a couple micro benchmarks. It really is only testing read/write performance. If you want to do real performance testing like you said you need to be running real world workloads. The database benchmarks in the paper cover some of them but also provides criticism about the nature of the workloads. The cool thing about the projects on those pages is that they allow you to capture the same workload and replay them on different filesystems. You can hope you get the same workload twice across two runs or you can capture the workload with tracefs and replay it with replayfs. Now this does introduce some overhead as these are stackable filesystems so they are going to add an additional thin vfs like layer to your analysis but if both of the filesystems have that you can factor that overhead out and get performance data for each filesystem individually. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Headsup! krb5 ccache defaults are changing in Rawhide
On 02/24/2012 00:22, Simo Sorce wrote: On Thu, 2012-02-23 at 20:41 -0500, David Quigley wrote: On 02/23/2012 14:28, Stephen Gallagher wrote: Dear fellow developers, with the upcoming Fedora 18 release (currently Rawhide) we are going to change the place where krb5 credential cache files are saved by default. The new default for credential caches will be the /run/user/username directory. The reason is to make credential saving a bit more predictable while at the same time avoiding races. Along the road we also gain a little bit more security by the fact that /run is a tmpfs and therefore cached credentials are automatically removed if the machine is shut off. We have opened bugs to change the default location in libkrb5 https://bugzilla.redhat.com/show_bug.cgi?id=796429 in sssd https://bugzilla.redhat.com/show_bug.cgi?id=786957 and nfs-utils https://bugzilla.redhat.com/show_bug.cgi?id=786993 Normal users should not experience issues once these components are fixed, however because the /run/user/username directory is created by PAM it means this directory is not normally created for daemons that may run as a system user. One such case is mod_auth_kerb that recently gained the ability to kinit with an HTTP/ keytab in order to support the s4u2proxy feature. For daemons that use a keytab to kinit because they act as clients (as opposed to just server that accept kerberos connections), it may be needed to add a configuration snipppet in their configuration file under /etc/tmpfiles.d so that /run/user/username is created with the correct permissions (700) and user ownership. For example, httpd would add the following line to the /etc/tmpfiles.d/httpd.conf: d /var/run/user/apache 700 apache apache If you know your daemon requires a credential cache file and does not specify one on its own but instead relies on the default location, then you should open a ticket in bugzilla and add the necessary configuration to tmpfiles.d If you have any questions feel free to contact any of the people in CC. -- Stephen Gallagher * Red Hat, Inc * Massachusetts (apologies if you get this twice. I sent it from the wrong address.) Please make sure to have any SELinux related things fixed at the same time (setting proper labels, extening policy etc). Where are the creds currently stored? Once we have that one of us can check if the old and new locations have the same security information or if we have to fix that. Dan Walsh is one of the owners of the feature. You can blame him if SELinux policies are broken! :-D Simo. -- Simo Sorce * Red Hat, Inc * New York Ok just wanted to make sure that Dan or one of us was involved. I'll make sure to blame him if things break :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Headsup! krb5 ccache defaults are changing in Rawhide
On 02/23/2012 14:28, Stephen Gallagher wrote: Dear fellow developers, with the upcoming Fedora 18 release (currently Rawhide) we are going to change the place where krb5 credential cache files are saved by default. The new default for credential caches will be the /run/user/username directory. The reason is to make credential saving a bit more predictable while at the same time avoiding races. Along the road we also gain a little bit more security by the fact that /run is a tmpfs and therefore cached credentials are automatically removed if the machine is shut off. We have opened bugs to change the default location in libkrb5 https://bugzilla.redhat.com/show_bug.cgi?id=796429 in sssd https://bugzilla.redhat.com/show_bug.cgi?id=786957 and nfs-utils https://bugzilla.redhat.com/show_bug.cgi?id=786993 Normal users should not experience issues once these components are fixed, however because the /run/user/username directory is created by PAM it means this directory is not normally created for daemons that may run as a system user. One such case is mod_auth_kerb that recently gained the ability to kinit with an HTTP/ keytab in order to support the s4u2proxy feature. For daemons that use a keytab to kinit because they act as clients (as opposed to just server that accept kerberos connections), it may be needed to add a configuration snipppet in their configuration file under /etc/tmpfiles.d so that /run/user/username is created with the correct permissions (700) and user ownership. For example, httpd would add the following line to the /etc/tmpfiles.d/httpd.conf: d /var/run/user/apache 700 apache apache If you know your daemon requires a credential cache file and does not specify one on its own but instead relies on the default location, then you should open a ticket in bugzilla and add the necessary configuration to tmpfiles.d If you have any questions feel free to contact any of the people in CC. -- Stephen Gallagher * Red Hat, Inc * Massachusetts (apologies if you get this twice. I sent it from the wrong address.) Please make sure to have any SELinux related things fixed at the same time (setting proper labels, extening policy etc). Where are the creds currently stored? Once we have that one of us can check if the old and new locations have the same security information or if we have to fix that. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Sat, 30 Apr 2011 18:44:13 +0200, Kay Sievers wrote: On Sat, Apr 30, 2011 at 02:54, Lennart Poettering wrote: On Fri, 29.04.11 17:46, Greg KH (g...@kroah.com [1]) wrote: I think /srv actually makes a lot of sense. Probably not so much on the desktop, but the boundaries are blurry, and I see no reason to set things up differently in this respect between servers and desktops. I see little benefit in removing this directory. I think moving /selinux is a bit more complicated then just a simple kernel change. We have libselinux changes, Lots of tools have learned over the years the path of /selinux and lots of users know about it. I am willing to work towards the goal of moving /selinux, but I might end up with a symbolic link if we can not fix all of the problems. A symbolic link from /selinux to point at /sys/fs/selinux/ is a good idea to help people migrate. The startup tools should be able to create this if /sys/fs/selinux/ is not present, right? This is not necessarily easy to do actually, since for upgraded systems /selinux needs to be an actual directory in the rootfs to be useful as mount points. At boot time the rootfs is read-only, hence removing the dir then and turning it into a symlink is difficult. However, we can use the same approach as we did for moving /var/run to /run: on new installs create it as a symlink and on upgrades simply make it a bind mount. For the long run we could also add %post scripts to filesystem.rpm which moves away the old /selinux, and recreates it as symlink. Unfortunately that cannot be done completely atomic, but that property is not really necessary here anyway I think. So, yeah, it isn't super-pretty doing this move, but we can handle it more or less exactly like the /var/run → /run move. Sounds all fine. I think we should get the kernel patch merged as soon as possible. It will not harm anything if we don't use it now, and continue to use /selinux as long as needed. But it will definitely help solving the chicken egg problem when we are ready to do the switch. Kay Resending since I sent from the wrong email address and devel rejected it. Merging the kernel patch without doing the legwork for userspace first is a very bad idea. The kernel is what mounts the FS under /selinux so if you have it mount under /sys/fs/selinux instead without coordinating with the required usespace changes you'll have a completely broken system. I'd say let Dan handle when the right time to merge the kernel patch is since both him and the tresys people will have to be involved with releasing new versions of libselinux . Also Dan will have to work with some of the package maintainers to cleanup and fix their packages as well. I'd really not like it if I can't test new kernels with my labeled-nfs patches because we merged an ABI breaking change into mainline without making sure people can handle it first. Links: -- [1] mailto:g...@kroah.com [2] mailto:mzerq...@0pointer.de -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
