Re: [arch-general] Thoughts
On 8/15/18 10:18 AM, Yury Grebenkin via arch-general wrote: > I wrote a book. It has several lines on Arch Linux. People interested, > please let me know and I will send you a copy as a plain text file > attachment. > > Yury Grebenkin Hello, you've got me curious. Would you mind sending the text file? -wilson
Re: [arch-general] Bad md5sum or bad download for archlinux-2015.02.01-dual.iso
David C. Rankin wrote: Is there anything other than hardware that could account for this? The drive in the laptop is [etc.] Bad RAM is a common source of data corruption along those lines. Try booting a memtest disc? --- Drake Wilson
Re: [arch-general] gnupg 2.1 not stable
Doug Newgard wrote: LOL, are you serious? Do you know how long Arch operated without package signing? You now expect users to panic? That's actually why I didn't run Arch before despite liking a lot of the philosophy. The big sticking point. The only real reason. Fortunately, now that I _know_ about this, due to the surrounding philosophy of simple composability and user-centric control, it may become possible for me to tweak my systems like earlier in the thread if I decide the main packagers are playing too fast and loose with GnuPG versioning. The upstream release cycle seems a bit unclear and does not play particularly cleanly with the notion of rolling-release Linux software distribution; the wording on the website doesn't distinguish well how comparatively stable the modern branch can be expected to be. I do certainly think GnuPG is a special case and should be more carefully integrated, even if it requires bending the general principle of avoiding lagging upstream. It's not clear to me whether falling back to the stable GnuPG is a good way to do this. I think _if_ modern can be demonstrated to be a /de facto/ development branch right now then it should be relegated to a more-experimental package, but there's potential follow-on problems surrounding how many users test the rest of the system with a newer GnuPG. Has upstream actually been contacted about this to ask what they think? --- Drake Wilson
Re: [arch-general] don't casually do things in /tmp directly (was: Strange issue)
Neven Sajko wrote: I used makepkg to build a package from /tmp. The package was then put to the designated directory and a symlink to pwd. When I try to install it with pacman -U /tmp/symlink-to-package, I get an error (permission denied) which I don't get when invoking pacman -U directly with the name of the file (not with the symbolic link). See, like this: [root@lnv64 tmp]# pacman -U /tmp/lomoco-1.0-9-x86_64.pkg.tar loading packages... error: '/tmp/lomoco-1.0-9-x86_64.pkg.tar': permission denied [...] So from this line: access(/tmp/lomoco-1.0-9-x86_64.pkg.tar, R_OK) = -1 EACCES (Permission denied) we see that the kernel call access() reports that root doesn't have read access to a 777-permissible file?! Maybe it matters that it's on tmpfs and/or a symlink? This is probably due to the fs.protected_symlinks sysctl being turned on, which I believe it is by default in Arch. Most symlinks in world-writable sticky directories (like /tmp) are not followed except by processes running as the user that created them. This is to prevent common attacks where a privileged process tries to access what it thinks is not a symlink, but another process manages to insert a symlink to an unrelated file so that the privileged process performs the wrong access. It's not a good idea to build things directly in /tmp like that anyway, for more or less that reason. Creating a subdirectory of /tmp for each new action that needs temporary files is a better approach. --- Drake Wilson
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26/09/14 07:06, Mailing Lists (???) wrote: Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make that much of a difference. From what I've read, most of the problems come from CGI scripts which invoke bash, and ssh post-authentication. Anything that uses system(), popen(), or other similar invoke command (implicitly via /bin/sh) functions can be affected by problems with whatever is installed as /bin/sh. Some daemon configurations have lines for hooks: invoke shell command when event occurs, with information passed to the command by various means (parameters, environment variables, etc.). Some programs allow specification of I/O targets as pipes to or from shell commands. There is a _lot_ of magic behavior in bash. Debian bug #762839 mentions how bash still imports shell functions from environment variables with magic names, even when called as sh. The --posix option seems something of a joke. dash has some of this as well (in particular, it interprets CDPATH) but not nearly as much, and it's much less likely to gain more in the future. I would support a move to dash as sh, but it's not primarily for security per se but for general cleanliness: bash as sh does more to encourage the proliferation of presumptive bashisms and has much more potential for future breakage in central system areas. I believe this is more in line with Arch's Simplicity and Code-correctness over convenience principles than conflating the needs of interactive and whole-system-default shells for convenience's sake, especially if bash is a moving target regarding which features might be enabled that might interfere with global functionality. I would not support a move of the _packaging_ system to another sh, because that's explicitly documented to use bash as its main scripting language and relies on its extended features, and the potential complications are better contained. I don't think that's relevant unless the current packaging system assumes that bash can be invoked as sh. The case of interactive SSH is separate, because that depends on the user's interactive shell, not sh. The case of machine SSH in which the target account's shell is sh falls loosely into the program-program interoperation category. On my own desktop system, when I realized sh was bash recently I immediately relinked it to dash and intend to keep it that way as long as I reasonably can (I assume some things may break, in the current state; I'm willing to deal with that on my own for now). --- Drake Wilson
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26/09/14 07:30, Drake Wilson wrote:
There is a _lot_ of magic behavior in bash. Debian bug #762839 mentions
how bash still imports shell functions from environment variables with magic
names, even when called as sh. The --posix option seems something of a joke.
Sorry, I mistyped; I meant magic values.
Incidentally this means that any environment variable of that form that
passes _through_ a bash instance to a subprocess will silently get mangled
in transit:
% env 'foo=() { true; true; }' bash -c dash -c 'printf %sn \\$foo\'
() { true;
true
}
The function definition was reconstructed from some internal form
and reinjected into the environment, as you can see. And of course during
the bash script itself it's not interpreted as a variable:
% env 'foo=() { true; true; }' bash -c printf '%s\\n' \\${foo-oops}\
oops
How much more of this hidden treasure is there?
(There might be another approach involving convincing bash upstream to be
much stricter in --posix mode or when invoked as sh or something, but that
seems like a lot more work and less reliable.)
Aside: I'm not sure about the interpretation of checkbashisms re autotools
scripts (in particular libtool) because they do an awful lot of weird code
generation and shuffling to deal with multiple bogus shell implementations.
--- Drake Wilson
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26/09/14 11:16, Leonid Isaev wrote: $ head -n1 /usr/bin/mkinitcpio #!/bin/bash --- So, yes ArchLinux core tools use and will continue to use 'bashisms' because they are convenient. Right, and I'm more or less fine with that _because_ of the above shebang line, and I'm also fine with bash being an essential package. When I say bashism I mean in the specific sense of programs that assume that /bin/sh is bash and casually break otherwise because they haven't been tested with anything else, not all bash scripting in general, nor even programs that assume /bin/sh is bash because it's been established as policy by some other means. Assumptions that happen to hold in too many cases by accident become dangerous cognitive shortcuts, and letting them get entrenched without thinking about them leads to bizarre, inescapable compatibility situations getting worse and impeding any further development. I admit feeling a bit insulted having my mail quoted as a witch hunt. The recent events were only a trigger to reëxamine something I'd considered doing ever since the first install a long while back. --- Drake Wilson
[arch-general] Out-of-date sbcl has fairly serious ASDF bug
(I originally attempted to send this to arch-dev-public, but apparently that's only for making discussions from a relatively closed circle visible? The list descriptions on the listinfo page were very ambiguous; if even things like packaging issues should go to -general if from third parties, perhaps the -dev-public description should be updated to be clearer about this.) The currently packaged sbcl 1.2.2-1 seems subject to the ASDF bug at https://bugs.launchpad.net/asdf/+bug/982285 where systems installed into /usr (e.g., according to the Arch Linux Lisp Package Guidelines) are not found when the environment variable XDG_DATA_DIRS is unset. (A workaround is to set XDG_DATA_DIRS to /usr/local/share:/usr/share explicitly.) ASDF upstream has fixed this, and SBCL upstream includes the fix in 1.2.3. The sbcl package was flagged out-of-date ~23 days ago on 2014-08-29. I would very much like to run with a newer packaged sbcl rather than limping along with the workaround. Is there anything I can do to help speed things along, or can I only wait for the package maintainer? I'm half-expecting there to be some careful coördination required with other Lisp packages, since SBCL is such a prominent implementation, but I didn't find any obvious discussion about any of this previously... --- Drake Wilson
[arch-general] GDM and/or PulseAudio mute my sound
According to Kyle: Apparently, Google is not my friend this time, as I can find no information about this problem, and I appear to be the only one experiencing it, and only on this machine. Correction: I actually did find [1], and that appears to be my exact problem, but it is also unsolved. Please help. Thanks. [1] https://bbs.archlinux.org/viewtopic.php?id=130201 ~Kyle Hi Kyle, I think I have also been having the same problems with pulseaudio on Arch. Basically pulseaudio seems to mute and zero the master channel on my sound card (its a VirtualBox machine) whenever it starts. I asked for help on the pulseaudio mailinglist back in June [1], but nothing much came out of it. I then gave up for a bit, but have been meaning to raise a bug on it. So this weekend I did so [2,3]. [1] http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-June/013710.html [2] https://bugs.archlinux.org/task/31469 [3] https://bugs.freedesktop.org/show_bug.cgi?id=54673 Cheers, Frank
[arch-general] Read permissions on /var/log/auth.log being reverted
Hi group When I make my auth.log file world-readable (big security risk), the system reverts it to unreadable by world. Could someone tell me what kind program/daemon is changing the permissions back and if said daemon has a log somewhere. I would like to shake its hand. something out of cron? This is Arch running in a hosted VM environment. Thanks E Wilson (New Linux and Arch User)
Re: [arch-general] Read permissions on /var/log/auth.log being reverted
Wow, didn't know syslog did all that. I won't be changing the
permissions though, but now have more to learn. Thanks a bunch.
E Wilson
On 6 September 2010 15:46, Gerardo Exequiel Pozzi
vmlinuz...@yahoo.com.ar wrote:
On 09/06/2010 02:37 AM, E Wilson wrote:
Hi group
When I make my auth.log file world-readable (big security risk), the
system reverts it to unreadable by world. Could someone tell me what
kind program/daemon is changing the permissions back and if said
daemon has a log somewhere. I would like to shake its hand. something
out of cron?
This is Arch running in a hosted VM environment.
Thanks
E Wilson
(New Linux and Arch User)
in /etc/syslog-ng.conf
-destination d_authlog { file(/var/log/auth.log); };
+destination d_authlog { file(/var/log/auth.log perm(0644)); };
good luck!
--
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1
[arch-general] Acer Aspire One Instalation Issues
Hey all I'm having a major issue with the installation on my Aspire One. I've used unetbootin to create the USB startup disk and I've succesfully booted from it, but a few seconds into the startup process, I get the following: /sbin/hwdetect: line 336: 506 Segmentation fault modprobe $i /dev/null 21 ath_hal: module license 'Proprietary' taints kernel. ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133) wlan: trunk ath_pci: trunk I've also tried this as well: http://bbs.archlinux.org/viewtopic.php?pid=283021 but when I come to reboot, I'm not presented with the menu that was mentioned and the thing just boots normally. I've tried it with the Fedora installation and it works fine there, so there just seems to be a problem with the Arch version. Thanks in advance for any help offered Chris
