On Fri, 10 Aug 2012, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: > > What is kerberos doing under /tmp and why is it being done repeatedly by > > different processes? > > Actually /var/tmp/HOST_0 /var/tmp/HTTP_23 ... Kerberos Replay Cache. > Every time someone contacts an apache server using kerberos it needs to > update this file, it does this via mktemp (/tmpHTTPD_23XXXX), rename. When replacing an existing file wouldn't it be better to just copy the context of the existing file when creating the replacement? If there was some good reason for running chcon on such a file (and I can't imagine a reason but it's best to leave the options open IMHO) then having the context change back the next time someone connects seems like a bug. > >> Running make install has caused a huge hit if you are running thousands > >> of install commands which caused the remove of labeling from the install > >> command. > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638304 > > > > I believe that is a design bug in the SE Linux code in install, I've > > filed the above Debian bug report about it. > > > > I think that correct design of install wouldn't have a "make install" > > performed as part of a dpkg or rpm build do any SE Linux checks. That > > would be faster than any other option. > > Programmers and testers regularly run make install and this ends up badly > mislabling files all over the place, telling everyone they have to use rpm > or dpkg is not going to fly. The current behavior of dpkg-buildpackage (and presumably a similar RPM build) producing lots of warning messages from install (depending on where you build it) isn't great either. Would it be possible to have dpkg-buildpackage (and other relevant programs) set an environment variable to modify the behavior of install in such situations? Also note that as install doesn't apply such contexts when creating directories the problem of testers running "make install" isn't properly solved with the current code. > >> Systemd has been is executing the load load many many times and is > >> showing up to 1 second slow down on startup. If the startup is 10 > >> seconds, it is kind of hard to justify 10% slowdown on boot. > > > > Wow, who's got a 10 second boot? > > > > Is systemd loading the file contexts 100 times? If not then why is it > > taking a second? > > 10 second boot is available with solid state machines. Systemd has not > seen the kind of performance that you are and obviously this is sensitive > to the speed of the CPU/Memory. Why isn't systemd seeing the same performance? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
