[OT] Tim, Gil, et. al. (e-mail address settings)
To keep this off-list as much as possible, the rant is here: http://reiisi.blogspot.com/2016/07/to-gil-tim-fedora-et-al.html (The blame lies elsewhere. I wish I had the network and social cred to get a real movement started, away from the current faceless CA system and towards a different identity assurance system that depends on actual, existing day-to-day trust relationships.) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Am I still blacklisted?
It doesn't matter any more, just curious. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prefered way of configuring X11 keyboard layouts in F18
On Fri, Jan 4, 2013 at 7:23 AM, Adam Williamson awill...@redhat.com wrote: On Mon, 2012-12-31 at 15:01 -0800, Adam Williamson wrote: As discussed in the bug, if systemd-localed is doing 'fuzzy matching' it may be the case that we actually get a decent match for most layouts, I'll have to do more testing. But the situation is clearly different to the F17 one in that we are now relying on systemd-localed to map xkb layouts to console ones, where we really weren't before. There is certainly at least a potential for regression here. The systemd-localed list of keymaps may not have regressed but it has taken on more significance. OK. Since that last mail I investigated things in quite a lot more detail. The big takeaway from that: the gap between 'kbd' and 'xkb' coverage is just way too large for this 'mapping' solution to be practical going forward. We really need the code to support xkb layouts at the console, it is the only sane way forward. I have sent patches to systemd to improve the xkb-kbd mapping a little bit, but there are just huge swathes of layouts xkb has which kbd simply does not have, and there's no way to patch around that. We simply need to ditch kbd and have One True Source Of Keymaps. This should be a high priority for F19 development. If I could write code, this is the code I would be writing. Either way, this is the kind of code I used to enjoy writing, back in another life. Too bad I have to work at something else these days to pay rent and feed the wife and kids. But, knowing first hand about how many different keyboard layouts, controllers, manufacturers, sources of the maps and other documentation, etc., there are, I'd agree with your conclusion that it's a lot of work to go to for not much gain, to duplicate the xkb keymaps for kbd. I'm definitely guessing that all the strange irregular details make automated conversion a really hard problem. Setting up different automatic conversion programs for different classes of keyboards might be a good approach (and a good job for long-term job security if someone were paying for it). But I think it would not be particularly timely, relative to coming releases of Fedora. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
On Tue, Jan 1, 2013 at 1:03 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 31.12.12 07:38, John Reiser (jrei...@bitwagon.com) wrote: Cool, then write a sane tool that converts them online that doesn't pull in Perl and whatnot, Is 'awk' available? 'sed'? 'bash'? (I'm not kidding. Some systems prefer 'dash', which lacks arrays and other hard-to-substitute features.) How much of 'python' is allowed? 'lua'? In other words, please specify the desired environment, with cost (penalty) functions near the boundary. How about C? Which sets of libraries do we assume are installed? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boot chaining works, then? (Re: Replacing grubby with grub2-mkconfig in kernel install process)
So, ... On Tue, Jun 19, 2012 at 2:32 AM, Chris Murphy li...@colorremedies.com wrote: On Jun 18, 2012, at 4:08 AM, Kevin Kofler wrote: Chris Murphy wrote: Grubby does not work fine with GRUB 2, it creates sloppy menu lists that eventually break the advanced menu entries, as well as totally departing from any user customization of /etc/default/grub. … vs. grub2-mkconfig, which totally departs from any user customization in grub.cfg. It does not totally depart. It is merely (highly) not recommended to directly edit that file. There is indirect customization, which actually in many ways exceeds that of Grub Legacy. But this is an old argument, that ship has sailed. You gain flexibility in one place and lose it in another. I'm not convinced it's an improvement. Though on the other hand, running grub2-mkconfig is how upstream intends things to work. I've already been on this hill pulling my hair out over GRUB2's complexity and lack of well written documentation. However, I feel like I've passed this particularly large stone, the pain has subsided, and except during pre-release grub-mkconfig hasn't failed to produce a correct grub.cfg and bootable system. Not even once. So, with grub-mkconfig, I can expect to be able to chain safely to Debian from a Fedora-installed grub2 in the MBR? Not have mk-config find Debian's kernel and initrd, etc., like Debian's update-grub, but actually chainm, so that Debian can keep track of its latest kernel and Fedora can keep track of its latest kernel and I don't have to deliberately boot and update in both to make sure the the boot process calls the latest kernel no matter which I boot which from? (Not to mention that grub2 doesn't find my 3rd drive for boot purposes.) So. While grubby may do other things, even for GRUB2 dependent systems, the part where it comes up with the new entry should, in my view, just call grub-mkconfig to cause a new grub.cfg to be created. If grub-mkconfig isn't working reliably for some reason, it's a bug that needs to be fixed anyway. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, Jun 19, 2012 at 9:57 AM, Chris Murphy li...@colorremedies.com wrote: On Jun 18, 2012, at 6:36 PM, Kevin Kofler wrote: Chris Murphy wrote: On Jun 18, 2012, at 4:08 AM, Kevin Kofler wrote: Chris Murphy wrote: Grubby does not work fine with GRUB 2, it creates sloppy menu lists that eventually break the advanced menu entries, as well as totally departing from any user customization of /etc/default/grub. … vs. grub2-mkconfig, which totally departs from any user customization in grub.cfg. It does not totally depart. It is merely (highly) not recommended to directly edit that file. Running grub2-mkconfig automatically makes it not just (highly) not recommended, but basically impossible: Any edits will be trashed at the next kernel update! Which is why if grub-mkconfig is going to be used, the upstream prescribed editing procedure needs to be used. If inadequate, the inadequacy needs to addressed. As far as I'm aware, there is in fact no reason why you can't remove grub2 and replace it with grub (legacy) if it has the exact behaviors you prefer and require. Unfortunately, the original grub does not seem to find my other boots. I prefer GRUB2's self-produced grub.cfg's and I don't find it overly difficult to get the customization I want – except for the fact grubby steps on this, meaning I have to manually run grub-mkconfig to fix the grub.cfg at each kernel update. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Wed, Jun 20, 2012 at 2:49 AM, Jesse Keating jkeat...@j2solutions.net wrote: On 06/19/2012 04:32 AM, Reindl Harald wrote: Am 19.06.2012 09:53, schrieb drago01: On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. but it is NIT better it is a config full of crap and script-code this is pervers - short time ago there was introduced systemd saying shell scripts are evil and directly after that we introduce a boot-loader with a configuration where each init-script ever existed was nice compared against CIONFIGURATION != SHELL-SCRIPT You seem to think we, the Fedora project, have any sort of sway as to how things get written in their various upstreams. We don't, except for very few cases. Our choices here with grub2 are A) continue using grub1 and continue working with diminishing resources to keep grub1 working in the new environments a boot loader will be needed in. B) consume what upstream gives us in the form of grub2. C) Maintain grub1 ourselves (not that I'm volunteering.) D) Invent our own substitute (again, I'm not volunteeing.) You seem to be advocating for option C) throw up your hands and yell THIS IS UNACCEPTABLE, and then what? -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Tue, Jun 5, 2012 at 12:28 AM, Olav Vitters o...@vitters.nl wrote: On Mon, Jun 04, 2012 at 08:44:38AM -0500, Michael Cronenworth wrote: Matthias Clasen wrote: Its not his ignorance - he's on vacation for the next two weeks... Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was an hour after that as a pretty good indication Lennart was not going to reply. Unless the timing was coincidental of him packing his bags, I'm still sticking with my post. Expecting and more or less demanding a reply after calling someone ignorant... not nice behaviour. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel If Puttering really went on vacation after dropping a bombshell like that, well, I'm thinking he should recuse himself. Yeah. I'm getting personal here. Lennart has put a lot of edits into Fedora that are all about copying a design philosophy that has been disasterous where it has been used. (Or perhaps getting the Fedora community to do the grunt work on his Master's thesis on things that shouldn't be done in an OS?) Edits that will have to be rolled back if Fedora is to survive as the testbed for an enterprise class OS. Very costly edits. Edits that have been eating my sack time, which is why I've been taking it personal. But, as has been danced around in this thread several times already, allowing /tmp to consume half of a system's putative RAM is really, really perverse. (Unless you have stock in a company that sells RAM and CPUs with 32 bit addressing.) No, you can declaim how the system will auto-swap the RAM and adjust things for you, but that is adding to the cycles the CPUs have to waste doing things that are just plain unnecessary. tmpfs is there precisely because /tmp is not fast enough for certain applications. Those applications should know who they are. Leave it like that. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login on Fedora 17
On Thu, Apr 19, 2012 at 7:59 PM, Adam Williamson awill...@redhat.com wrote:
On Thu, 2012-04-12 at 08:02 +0900, Joel Rees wrote:
On Thu, Apr 12, 2012 at 12:06 AM, Mark Haney ma...@abemblem.com wrote:
On 04/11/2012 10:34 AM, Paul W. Frields wrote:
You can still login at this prompt with your 'root' account and
password. From that point, you can look at /var/log/Xorg.0.log to see
what happened that caused your X Window System to fail. If you want
to post that for people here to look at and offer advice, please
*don't* attach the file to your email. It will probably be too big
and your message won't come through. Instead, post it somewhere like
http://fpaste.org and send a link to your paste here.
That's true it is a fairly generic question, however, the OP did state he'd
tried to login with root and failed. Sounds to me like X wasn't the only
thing that is having issues.
Although it could be the password he used. I noticed one time that the
password I was using simply wouldn't work on the initial install of Fedora
no matter how many times I installed it. It did work however after
changing
it once I got it installed.
Maybe keyboard definition issues?
My hardware tends to be Japanese, and sometimes the difference in key
positions has left me with a root password set assuming US English
layout. Some of the punctuation keys move when the full system boots
and the keyboard definition is correctly set. If I work out what moved
where, I can log in.
But sometimes it's easier to just boot single user and set the
password again. (Don't have all the layouts memorized.)
Lately, I am beginning to doubt the wisdom of always hiding the
password when you're setting it, especially now that proper passwords
are generally understood to be long and convoluted. It would sometimes
be nice to have a Debug keyboard or I've checked, nobody's looking
over my shoulder, and I need to see what I'm typing. button.
Setting up a new system is, statistically speaking, sometimes going to
require some debugging until we can put the WINTEL-pseudo-standard
infected hardware behind us. (And I don't even see Apple trying to do
that, now.)
Of course, you can always try the keys that might have moved --
()[]{}'=;:+*-_\| and so forth -- where you'd type a user name. You
often have to think in reverse, of course, as in, I thought I was
typing left-bracket, what would that have been?
Note that we actually have a test case which is run during validation
testing and is intended to ensure that the same keyboard layout is used
for setting passwords during installation and entering them
post-install, because we had a lot of this kind of trouble back before
we did that. To my knowledge we haven't had a major bug of this type
since F15 or so.
Well, maybe that doesn't get applied to some of the spins?
I'm pretty sure I ended up with keys moving on a password on a live
USB of the F16 security spin. If I notice it again and have time,
maybe I should file a bug?
--
Joel Rees
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login on Fedora 17
On Thu, Apr 12, 2012 at 12:06 AM, Mark Haney ma...@abemblem.com wrote:
On 04/11/2012 10:34 AM, Paul W. Frields wrote:
You can still login at this prompt with your 'root' account and
password. From that point, you can look at /var/log/Xorg.0.log to see
what happened that caused your X Window System to fail. If you want
to post that for people here to look at and offer advice, please
*don't* attach the file to your email. It will probably be too big
and your message won't come through. Instead, post it somewhere like
http://fpaste.org and send a link to your paste here.
That's true it is a fairly generic question, however, the OP did state he'd
tried to login with root and failed. Sounds to me like X wasn't the only
thing that is having issues.
Although it could be the password he used. I noticed one time that the
password I was using simply wouldn't work on the initial install of Fedora
no matter how many times I installed it. It did work however after changing
it once I got it installed.
Maybe keyboard definition issues?
My hardware tends to be Japanese, and sometimes the difference in key
positions has left me with a root password set assuming US English
layout. Some of the punctuation keys move when the full system boots
and the keyboard definition is correctly set. If I work out what moved
where, I can log in.
But sometimes it's easier to just boot single user and set the
password again. (Don't have all the layouts memorized.)
Lately, I am beginning to doubt the wisdom of always hiding the
password when you're setting it, especially now that proper passwords
are generally understood to be long and convoluted. It would sometimes
be nice to have a Debug keyboard or I've checked, nobody's looking
over my shoulder, and I need to see what I'm typing. button.
Setting up a new system is, statistically speaking, sometimes going to
require some debugging until we can put the WINTEL-pseudo-standard
infected hardware behind us. (And I don't even see Apple trying to do
that, now.)
Of course, you can always try the keys that might have moved --
()[]{}'=;:+*-_\| and so forth -- where you'd type a user name. You
often have to think in reverse, of course, as in, I thought I was
typing left-bracket, what would that have been?
--
Joel Rees
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 08:10 AM, Joel Rees wrote: On Tue, Apr 3, 2012 at 3:27 PM, Tim ignored_mail...@yahoo.com.au wrote: s/some/a lot of/ if you set it up right. It can still do a fair amount of nasty stuff. xhost local:subuser-id; sudo -u subuser-id does pretty well with current applications. You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? There have been vulnerabilities of this kind in the past that allowed an attacker to quickly gain a root shell given the ability to connect to the X server. Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Now, if I'm going to my bank site, I do log out and log in as a different user, just to be extra safe. Now, I want to make it clear that I recognize that, if the bad guys have succeeded in taking over the bank site, restricting my internet banking access to an account that I do nothing else with doesn't protect me, relative to that bank. It may keep up some speed bumps and low walls relative to attacks on my machine, of course. I think you'd be better off taking a look at Daniel Walsh's blog posts on confining X applications with the SELinux sandbox. The first post introduces and explains the general sandbox concept: I am familiar with the sandbox principle, in several versions, thank you. Not that one more point of view or version ever hurt. http://danwalsh.livejournal.com/28545.html This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. And the follow up looks at extending this to untrusted X applications using a temporary xguest account (with dynamic $HOME and $TMP) and the Xephyr X-on-X server to provide much stronger separation between the sandbox and the rest of the system: http://danwalsh.livejournal.com/31146.html I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Fedora already provides contexts to use with the sandbox such as sandbox_x_t, sandbox_web_t, sandbox_net_t etc. depending on the particular resources you want to allow the sandbox to access. You know, one of the problems with ACLs (and capabilities) is getting them set up right. And you know how it ends up? Well, as you say, and as Walsh acknowledges, The post discusses future improvements to simplify retrieving files from the sandbox when the application exits but I'm not sure of the current status of that work. I've been trying to avoid what I'm sure amounts to blasphemy in the eyes of some on these lists, but I am not particularly fond of SELinux. Way too many convolutions to hide bugs in. If X11 must be assumed to have bugs, so much more, the more recent and more complicated SELinux, especially in the patterns by which the tools to set policy are run. I'm going to prefer to trust tools I can understand. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Tue, Apr 3, 2012 at 10:24 PM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 01:15 PM, Joel Rees wrote: On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? If the reason you are running the separate browser is to visit sites that you do not trust sufficiently to visit from your main user session then yes because the browser (and in turn X) is now exposed to those sites. Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in fact parallels of the technical reasons. Well, sometimes I have to go to some sites that I don't really trust that much, and I have a user I have dedicated to such uses. For example, Kickstarter. When I'm logged in there, I'll be on one of my work users. (Stupid Flash.) But when I'm browsing other projects, many of the links are offsite, so I shift to the subuser to browse projects, and if I need to link off-site, I'll log out and log in to the dedicated play user. Still not as good as having a separate machine, but better than nothing. If your choice is or do nothing and run them in the normal session then of course there is no difference. I think there is some difference. If I hit a drive-by when I'm browsing via a sub-user, for instance, the malicious payload will be in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? I'm no X expert but historically the X server needed root privileges to use vm86 mode to interact with the video BIOS and to access the IO ports for the card so KMS for all drivers at least is required to be able to support this. Yeah. OpenBSD modifies the Xorg source to allow privilege separation and this work has not made its way upstream (which is a problem for Fedora to include it). License issues? Getting the source should be now problem. There are also legitimate questions about how useful all of this is; although OpenBSD provides their aperture driver to minimize the address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. True, there are ways through that aperture, or around, but it's a bit of a higher wall than a speedbump. Would take some serious programming to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on your workstations. OpenBSD also provides a vesafb driver that permits an unprivileged X server with no aperture driver but acceleration is not supported and performance suffers as a consequence. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Yes; if you don't trust those applications or the data (sites) they operate on then you have a possible avenue for attacks. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. This is the point of sandbox -X. Which would be nice if I trusted ACLs. This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. SELinux doesn't provide ACLs (Linux ACLs are primarily a file system feature that's independent of other security frameworks in use). Wait. Doesn't provide or doesn't use? If neither, how does it implement those policies that I never can get right? I thought those policies were just a way to compile those lousy ACLs so you wouldn't be spending more time setting the ACLs than doing actual work. I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Just sane. Linux has supported per-process mount namespaces for a very long time. They provide far stronger isolation than other methods. They're
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Wed, Apr 4, 2012 at 2:05 AM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 04:56 PM, Joel Rees wrote: Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in There are a lot of perfectly family-friendly websites whose administrators I do not trust as far as I could throw them (even if I knew where they were). Exactly. I guess, though, that I am willing to use a separate login on those sites, rather than separate hardware on a separate segment of the internal network at home. At work, it would depend on what I'm working on. in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. If the payload targets an X vulnerability there is no difference. I assume that payloads that target the X vulnerability are significantly fewer. Not perfect, but you match the measures with the threat and your budget. License issues? Getting the source should be now problem. Upstream first - Fedora goes out of its way to get new features into the distribution by getting them into the projects it packages upstream (often by doing the work upstream). There are occasional exceptions but it's very unusual for Fedora to take a large set of changes from another downstream packager before they get merged. Woops. Guess I was forgetting that Fedora is not maintaining its own X11. address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. Thank you for enlightening as to what I meant (although what you assume I mean by that may not be the same as what I actually meant when I wrote it). Well, from where I sit, I have to guess that the openbsd engineers doing the aperture work are a bit more on top of the technical details than you. And I think you admit that. That's the gap I'm talking about. It is a relatively high wall, compared to some walls. to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on That's not the case at all. It's just a more constrained interface to the same thing (and Linux is fairly restrictive about that these days too). A smaller attack surface doesn't mean that you need targeted attacks; almost certainly if someone discovered an exploitable flaw in this it could be developed into an easily deployed local exploit just like any other. But tell me about real exploits. What I understood from Theo's statement is that while it tightens some avenues for exploit development the basic model of exposing hardware to a userspace process (privileged or not) is broken. Not everybody agrees but there is a lack of a usable alternative right now. Theo is dead right on that. Intel failed us on the processor design and only recently accepted the responsibility of providing MMU functions to enable making executable store non-writeable. There's a long way to go there, and, while the old 68K had the MMU capability in the architecture, competing with INTEL pushed the industry to fail to support it in the circuitry external to the CPU. And then, when the graphics processor manufacturers started up, there was no pressure to get it right, and a lot of pressure to not bother. Excessive competition is as much a sin as deliberate fraud. As is complacency (and collaboration) on the part of the OS vendors. (I say plural because there were alternatives to Microsoft in the mid-80s.) He also goes on to state that X: violates all the security models you will hear of in a university class. due to the exposure of the device registers, memory space and I/O ports to userspace (drivers in userspace model) and that the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this 10 year old problem. I am sure such words would motivate me to help him if I worked on X. Since soft words have failed to motivate the vendors, hard words are necessary. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) There are vesa drivers in Fedora. I have no idea how difficult it would be to coax them into running unprivileged but if it interests you you might want to look into it. Wish I had time. I don't really have time to be writing this. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. The evidence base disagrees here. Multiple studies find large declines in casualty figures following introduction of mandatory seatbelt laws: http://jech.highwire.org/content/43/3/218.full.pdf http://tinyurl.com/bu6ymdn [jstor] I'm not going to log
users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Sat, Mar 31, 2012 at 7:04 PM, Tim ignored_mail...@yahoo.com.au wrote: On Fri, 2012-03-30 at 20:39 +0100, James Wilkinson wrote: From there, it follows that the easiest way to do this is to make 002 the default umask, which means that all new files and directories created by normal users have these permissions. That means that if you want files that only their owner can write to, you need a per-user group. It always struck me that personal files ought to have no group or world permissions set by default. If you wanted your files to have those extra permission set, then it ought to be done as a deliberate choice. Maybe user-id is mis-named. There are sure a lot of people who tend to see user-id and expect the one-to-one correspondence. I know the conflation caused me some frustration back in college, and I'm not sure I got it properly worked out until I put together a few openbsd systems. Anyway, it should be clear that a system administrator should not be logged in as a system administrator when he or she is just writing an e-mail scheduling meetings or something. But even ordinary (human) users should not be surfing the web as the user they logged in as, and I'm not talking about keeping my boss from checking my cache for visits to slashdot or whatever. As the system administrator for my home box, I want to be able to log in as a normal user that is not tainted by my the web sites I visited last time I logged in. That means I have a separate administrator user. I want one user-id/group-id pair for each bank I have to visit, so that, even if we can't get the banks to use special-purpose browsers for the money transactions, I can protect the bank data from the guys that want to mine my data for their gain, including the other banks. (Special purpose browsers are preferred, of course.) And when I need to go surfing through blogs for news, I don't want to do that with the user I logged in as. Even if/when we can get rid of the sloppy programming practices Microsoft and their ilk promote, we can't be sure we have every hole plugged, so it's just going to be safer to do that as a user that isn't allowed to log in. That means that, even though I log out of my worker user and log back in as my play user, I still want to spawn a nologin user from there to surf. (This is not pure paranoia. I checked out a company for a job and discovered that Google had flagged their site as containing malware, and the guy who ran the company did not have the financial means or motivation to hire someone to clean the server up. Scared of having to move off the vulnerable tools he was using, trying to meet a market window that was fast disappearing, all the excuses.) Incidentally, I'm doing this much now, using xhost local and sudo. (If you're curious, http://reiisi.blogspot.jp/2011/08/simple-sandbox-for-firefox.html is my blog from when I first got it running. I need to re-write that explanation, which is part of the reason I'm writing this long-winded post now. But I still have issues with the input method that I need to solve. And I need to write some scripts so I don't have to all the tweaks by hand every time.) And I glue it together with per-user groups. Without per-user groups, I would have to go through serious admin-level contortions to grab a download. Does that make sense? -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Sun, Feb 5, 2012 at 7:36 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 3, 2012, at 12:06 PM, John Reiser wrote: Examining with gparted and Disk Utility, I see an Apple partition label that designates partitions: HFS (not plus) 1 MB boot HFS+ journalled 25.6 GB Machintosh HD ext3 10.6 GB Fedora root swap 1.0 GB I believe that the plain HFS boot partition was created during Fedora install. It's now running MacOS 10.4.11 and Fedora 12, which are both the latest applicable releases. I though you meant a user accessible volume being formatted as HFS. HFS+ and HFSX volumes must be greater than 32MB, where as HFS supports smaller sizes. As for the purpose of the 1MB HFS volume, it may be a Fedora PPC convention. I have a PowerPC machine dual booting two versions of Mac OS X, and the disk does not have an HFS volume on it. They are jhfs+. Sort of Fedora convention. Debian can use a larger disk to store the boot files. My impression is that the HFS volume made there is primarily for code that no one wants to fix, and to hide from the user slightly hairy boot incantations like boot hd:3,ofwboot /bsd (per the openbsd boot incantation for ppc). I personally would prefer to use ofwboot directly, because Fedora's gparted doesn't seem to be able to make volumes as small a 1M on disks larger than 120G or so, and every partition used by Linux for making things easier on the user is one less that could be used for multi-boot and such. But I haven't had success guessing which file to name in the above incantation on Fedora. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
Think MOL? I've never used it, but I would hate to block its use on Fedora. I'm planning to use it someday. On Sat, Feb 4, 2012 at 3:12 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 2, 2012, at 6:45 PM, John Reiser wrote: Does anyone object [to dropping support for HFS]? Plain HFS has no journal, so there are workloads where HFS is faster than HFS+ which has a journal. Mac OS Extended or HFS+ or HFS Plus, does not inherently have a journal. There is a separate variant called Journaled HFS+ (acronym appears as HFSJ or jhfs+). There is yet another variant called HFSX which is case-sensitive, but also has more feature potential than HFSJ. For nearly nine years Apple's tools have only created HFSJ/jhfs+ by default. Most of the reason for supporting HFS at all lies in seriously old legacy software. Much older than nine years. Is it economical to cater to such cases? Probably not. retro computing? Maintaining access to pre-historic data? (I keep thinking I want to get MOL or an equivalent emulator running on a Linus box so I can dump my ancient 68K macs like my wife wants me to. There's a sentimental resistance to dumping those boxes, but I haven't booted either in over a year, I think. Wait. I played around with an old Codewarrior compiler on one last summer. Heh.) [...] HFS is dead. I'm not even finding a partition type GUID for it, it was always intended to be used with the APM partitioning scheme (not MDB or GPT). Well, yeah, the partition type was a kind of half-baked attempt to help DOS-world OSses ignore Mac disks. I don't remember the flag number and I couldn't find it last time I looked, either. I think it got re-used by something more meaningful in the DOS-world. But, no, HFS isn't really dead. Old formats should not be allowed to die. I do want to be able to read my old media under emulation someday. Apple doesn't care, but I do. Sentimental fool that I am. :-/ -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Jan 27, 2012 at 10:10 PM, Harald Hoyer har...@redhat.com wrote: Hello Testers and rawhide Users, Fedora 17 will locate the entire base operating system in /usr. [...] You guys really are going to do this? If it were I, instead of combining, I'd be working through the list of what is where and starting to move things out of /bin, et. al., that don't belong there, and starting to split /usr even further. I guess this is what you get when you start using ACLs. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad package selection practices in Fedora packages
On Wed, Jan 4, 2012 at 10:40 PM, Olav Vitters o...@vitters.nl wrote: On Wed, Jan 04, 2012 at 03:09:07PM +0900, Joel Rees wrote: I suppose I have to go to the gnome lists and raise Cain about this kind of fundamental mis-engineering? If you want bugs to be fixed, then please file bugreports. I'm wondering if I'm the only one who sees the problems here. I suppose I'm going to have to register over there, get on the list, file the bug, and start teaching them the meaning of problem complexity, which they will initially see as rabble-rousing from an outsider. (Much as I'm sure my first post is seen here.) More time I don't have, especially if I take the time to avoid looking like a troll. Tracker should NOT have a noticeable impact on performance (in the default config). They keep saying that. They are wrong. They don't seem to understand some fundamental problems in the tech, which is demonstrated by their default setup. Of course it'll have some measurable impact, but if you can notice the impact in the default configuration, then something is wrong. How many cores, how much RAM, how fast are your CPUs, how much extra disk space before there is no measurable impact? What does this do to the low-power machines that we should all be switching to for our primary workstations? How does this scale across the network when you have, say, just 40 thin clients and a primary file/workload server in a classroom setting, for an easy example? And what does it do to security? Why is there a tracker-flickr that has to be turned off, and what was the user that tracker-flickr was running as? And what was it reporting back to who-knows-where through that social network? Who let that run that way and why? From what I understood (before GNOME 3.0), tracker was changed so the performance impact is not noticeable. E.g. I have tracker running but I don't notice the impact of it. I do not have an SSD. I think I missed that other thread about misusing the kernel, so have to read up on what was said there. What has been said has been missing the point. The sort of desktop search that they are trying to enable falls into a class of problem which must be solved by programs that, when you class them as mathematical languages, are known as an unrestricted grammars. Unrestricted grammars will sometimes go into serious recursion thrashing, trying different branches of solutions and throwing them away. That's the way they work. You avoid that somewhat in thjis case by pre-searching the file system, and that pre-search was what killed the overall system response time for the first several hours (days in some cases) after a new install. But the pre-search was searching things it should not have been searching (which is part of the reason for the huge startup load). By default, each user should have his own database, and nothing outside that user's own file (sub)system should be in it. By default, that database should not be built until the first time the user goes to use the thing, and should only be built for the parts that are being searched. But those defaults conflict with the desire to make search results available without wait the first time the user wants to search. They have not dealt properly with those sorts of conflicting definitions in the design. And then there are those programmers who think that this will be a cool way to finally get a handle on their source code. No. That does not work. Not if you expect to use the machine for any other job, not if you expect to develop code on the same machine. Even when the indexing operation doesn't clash with a running build, indexing all those source files would be a huge burden on however many cores you have. If you want to have /usr/share indexed, it should be a separate index, owned by a man user. (Don't get me started on ACLs and capabilities. Not today, not in this thread.) No one should ever want to use this desktop search function to index /bin or /usr/bin, much less /sbin or /usr/sbin. (And there's another tangent I want to avoid for now.) In fact, there is very little outside /home that should ever be indexed. Backup file systems, maybe, but the indexes in those cases should look quite a bit different. The locate databases should be sufficient for those. PS: Didn't know the term raise Cain, but if you mean: To be 'raising Cain' is to be causing trouble or creating an uproar. Cain was a rebel and a rule breaker. Caused his parents a lot of grief. Raising Cain is often used as an idiom for causing trouble, but the proper use of the expression is the converse, the various ways his parents tried to teach him the error of his ways (which Cain, of course, considered a lot of trouble). Don't do above @ GNOME, would only cause you to be banned. If I allocate the time for it, I'll be sure to do so carefully, and try not to sound as much like a stupid know-it-all as I'm sounding here. I'm posting here, using language that is more blunt than I
Re: Bad package selection practices in Fedora packages
On Wed, Jan 4, 2012 at 6:00 AM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Tue, Jan 3, 2012 at 1:06 PM, mike cloaked mike.cloa...@gmail.com wrote: I also discovered that three different tracker processes were running in my xfce desktop! However since I don't see a need for them for me, nor do I want them, it was relatively easy to prevent them from executing on desktop startup by going to The Applications menu, then Settings-Session and Startup and under the Application Autostart tab then switch off Tracker File System Miner, Tracker Store and Tracker Miner for Flickr as three separate switches - after that there are no tracker processes running after the next login. and if necessary the cache files can be removed as well. Annoyingly, I also have tracker processes on KDE. You'd think the GNOME apps that need that stuff could use KDE's bits, and vice versa, given that they their both based on Nepomuk. *sighs* I guess there are analogous switches in KDE too that might help make KDE actually work as a much snappier desktop? In fact I abandonned KDE for xfce because it was simply too slow logging in for my liking. All this in f16 but others may have a different experience of course? If this makes KDE a usable desktop again I might even try it when I have a bit of spare time! For desktop search specifically, go to System Settings Desktop Search and uncheck everything on the first tab. KDE's equivalent to GNOME's Session and Startup is the Startup and Shutdown panel in System Settings, so you can disable other unwanted services too. I feel like I'm the only Fedora user on the planet who actually does like desktop search. I love that I can press ALT+F2 and play a movie or e-mail somebody just as easily as I've always opened programs from there. IMHO, it beats trawling through even the most well organized directory structure. The problem with it for most of us is we have gobs of crap in $HOME, so it takes a lot of juice and space to index it all. If you configure it to only search in places where desktop search is actually beneficial, it uses a lot less resources, and the signal-to-noise ratio is such that its much more useful. I think the error here is less in the coding in packages than in the design of the default system specifications, specifically the package selection. The errors gnome has committed would seem to be off-topic here, unless the Fedora community still needs more evidence of how far gnome has gone evil, or still needs more fuel for the debate about whether/when/where said evil should be considered necessary. The Fedora community should be able to decide which packages to group together for which installs. I do not look forward to updating to F16. With all the stuff I expect to have to shut down and tweak, I'm thinking I might as well start with a CLI only base install, the way things are done in openbsd. Tweaking is tweaking, and tweaking while you build is more constructive than tweaking while you chisel and pare. I do plan on trying F16, anyway. I hope that, if I opt out of desktop search there, as I did when I installed F11, it will still keep me free of that evil. The locate database is sufficient for my purposes. Package selection needs to be somewhat more conservative, and I have the impression that the dependency mapping needs re-work. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad package selection practices in Fedora packages
On Wed, Jan 4, 2012 at 10:35 AM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-01-04 at 09:52 +0900, Joel Rees wrote: I think the error here is less in the coding in packages than in the design of the default system specifications, specifically the package selection. The errors gnome has committed would seem to be off-topic here, unless the Fedora community still needs more evidence of how far gnome has gone evil, or still needs more fuel for the debate about whether/when/where said evil should be considered necessary. The Fedora community should be able to decide which packages to group together for which installs. The desktop team decides what packages go into the desktop spin, and that's the same group of people as maintain GNOME, and many of them are upstream GNOME developers. Their stated position on tracker - it's been brought up on the desktop list before, see https://lists.fedoraproject.org/pipermail/desktop/2011-September/007377.html - is: Yeah, tracker is a required dependency of gnome-documents now. As Bastien says, we should try to identify and fix possible bugs and resource issues upstream. Had to go down a few posts to see that. But thanks for the broader thread. i.e., Tracker is now part of GNOME and they don't intend to disable it by default, but its default configuration could be adjusted (there was some discussion in the thread of doing this), and resource consumption bugs should be reported upstream and fixed. https://lists.fedoraproject.org/pipermail/desktop/2011-September/007395.html Hmm, so investigating this further with strace it appears to me that tracker is trying to make use of the kernel in a way it shouldn't. Or to put this another way: our infrastructure (the Linux kernel) isn't ready for tracker yet. And yet Poettering proceeds with talking about how to shim Tracker in, and the thread gets lost in wondering how to push the development of fanotify ahead so it do what inotify can't. No evidence that anyone is considering whether there is a fundamental conflict in requirements -- security vs. convenience, expecting context-free performance when executing an unrestricted grammar on a very large finite state machine. I suppose I have to go to the gnome lists and raise Cain about this kind of fundamental mis-engineering? If I had any influence here, which I don't, I'd be pushing for Fedora to kick gnome3 back to the curb and put its weight behind the gnome2 fork. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
