Re: [arch-general] Thunderbird 78
On 09.11.20 17:27, Jens John wrote: Just don't bother with Arch's release cycle and use Mozilla's build, either directly (with auto updates) or through https://aur.archlinux.org/packages/thunderbird-bin/. That's what I did not. I uninstalled the thunderbird package completely and used Mozilla's build with auto update until Arch finally gets the needed security updates shipped. If there is a small percentage of Arch users which has issues with GPG, maybe it would be better to ship TB 78 and this small percentage of users uses Mozilla builds until the pending bugs are fixed? This would provide a more secure environment for the Arch userbase... Manuel
Re: [arch-general] Thunderbird 78
On 08.11.20 07:18, Archange via arch-general wrote: anthraxx did update the PKGBUILD and we are testing the build but currently for instance I’m unable to decrypt messages using the external GnuPG feature (reported upstream), and there is also a build issue with system bzip2 (I used the vendored one instead, but that’s not what we want for the final build). So for now this remain WIP. Can this at least be built and placed to "testing"? This would offer at least some way to easily get pending security updates installed without manual compiling. Manuel
[arch-general] Can anyone share experience with "preloader" on Arch (UEFI secure boot)?
Hello, I want to occasionally run Linux on a system which was set up with Windows 10 with Bitlocker enabled. Disabling secure boot for Linux and reenabling it when booting into Windows starts to get annoying. So my idea was to just use "preloader" and add it to the chain of EFI binaries to execute. But as Arch gets kernel updates pretty often I am a bit worried about getting my MokList corrupted at some time as described here: http://blog.rootserverexperiment.de/2013/06/02/moklist-gesemmelt-boot-unmoglich-moklist-corruptet-boot-impossible/ Has anyone ever noticed this problem? How are the hashes stored? If I update the kernel, will preloader *replace* the hash in MokList or add a new one? How is this MokList stored? Is this flash memory with limited write cycles? Thanks Manuel
Re: [arch-general] No login after update
On 21.08.20 22:23, Manuel Reimer wrote:
A diff between the actuall file and its ".pacnew":
$ diff -U 8 -p 00-dns.sh 00-dns.sh.pacnew
--- 00-dns.sh 2013-05-30 19:35:30.0 +0200
+++ 00-dns.sh.pacnew 2020-02-20 22:37:04.0 +0100
@@ -1,7 +1,11 @@
#!/bin/sh
if [ "$USEPEERDNS" = "1" -a -f /etc/ppp/resolv.conf ]; then
- [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
- mv /etc/ppp/resolv.conf /etc/resolv.conf
- chmod 644 /etc/resolv.conf
+ if [ -x /usr/bin/resolvconf ]; then
+ /usr/bin/resolvconf -a ${IFNAME} + [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
+ mv /etc/ppp/resolv.conf /etc/resolv.conf
+ chmod 644 /etc/resolv.conf
+ fi
fi
And here the dates of the files:
$ ls -lh
total 8,0K
-rwxr-xr-x 1 root root 229 30. Mai 2013 00-dns.sh
-rwxr-xr-x 1 root root 344 20. Feb 2020 00-dns.sh.pacnew
So when copying over from HDD to SSD I seem to have taken care of
keeping the filestamps as I did not have my SSD in year 2013.
If pacman had a bug in the past which did not properly move .pacnew into
place (or maybe the "move into place feature" came some time later).
Could a existing ".pacnew", created from older pacman versions, cause
issues here?
This is a pretty old Arch install. Never reinstalled. Always just
updated. The oldest date I could find is August 2012.
Manuel
Re: [arch-general] No login after update
On 21.08.20 22:09, Morten Linderud via arch-general wrote:
There are more ".pacnew" in my /etc. All for files that I never touched
myself.
That is concerning, but it is simply something touching those files you are
unaware of. It's however you system and it's expected that you are aware of what
does this.
I don't know what this could be. What exactly is compared? File
timestamps? Checksums? How to debug this?
For example I have a /etc/ppp/ip-up.d/00-dns.sh.pacnew
I for sure never edited this. I don't care about ppp at all. This
package came as dependency of something else (maybe NetworkManger).
A diff between the actuall file and its ".pacnew":
$ diff -U 8 -p 00-dns.sh 00-dns.sh.pacnew
--- 00-dns.sh 2013-05-30 19:35:30.0 +0200
+++ 00-dns.sh.pacnew2020-02-20 22:37:04.0 +0100
@@ -1,7 +1,11 @@
#!/bin/sh
if [ "$USEPEERDNS" = "1" -a -f /etc/ppp/resolv.conf ]; then
- [ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
- mv /etc/ppp/resolv.conf /etc/resolv.conf
- chmod 644 /etc/resolv.conf
+ if [ -x /usr/bin/resolvconf ]; then
+/usr/bin/resolvconf -a ${IFNAME} +[ -e /etc/resolv.conf ] && mv /etc/resolv.conf
/etc/resolv.conf.backup.${IFNAME}
+mv /etc/ppp/resolv.conf /etc/resolv.conf
+chmod 644 /etc/resolv.conf
+ fi
fi
I guess there is something wrong with the way how pacman decides when to move
".pacnew" into place directly.
There isn't. Peopel with `.pacnew` has modified their files, wittingly or not.
For sure not. I guess it somehow also depends on how they are compared.
At some point in the past I replaced my HDD with an SSD and as far as I
remember I copied over the system. Could this have caused the way how
pacman decides when to move ".pacnew" into place somehow?
I may also have deleted the whole /var/cache/pacman/pkg at some point in
the past to save space. Is this where pacman checks for "old files"?
Manuel
Re: [arch-general] No login after update
There have to be edge cases where the replacement does not happen even if I never touched a file myself. But I don't know how to debug this. There are more ".pacnew" in my /etc. All for files that I never touched myself. And about the "system-login"-thing: I'm not the only one who had this problem: https://www.reddit.com/r/archlinux/comments/id6tem/cant_login_as_user_or_root_after_upgrade/ https://www.reddit.com/r/archlinux/comments/ie3i8d/super_weird_login_problem/ https://www.reddit.com/r/archlinux/comments/idjpw3/issues_with_pam_tally2_after_full_system_upgrade/ https://www.reddit.com/r/archlinux/comments/iczyr0/psa_be_careful_with_pacnew_when_updating/ https://www.reddit.com/r/archlinux/comments/id3dsu/unable_to_login_after_upgrade/ https://www.reddit.com/r/archlinux/comments/id6ce4/not_able_to_login_after_updating_pam_to_1403/ https://www.reddit.com/r/archlinux/comments/icnzrx/after_latest_update_my_computer_cant_login/ https://www.reddit.com/r/archlinux/comments/icr4sv/incorrect_login_with_correct_password_even_reset/ And maybe more. I guess there is something wrong with the way how pacman decides when to move ".pacnew" into place directly. And I'm wondering how many users actually got lost with this issue of not being able to log in after updating and just wiped Arch off their hard drive... :( IMHO something should be done to at least find out why pacman does not replace *non user modified* files in some cases... Manuel On 19.08.20 21:07, Josef Miegl wrote: This can only happen if you or another program modified the original file. Josef Miegl On August 19, 2020 9:02:12 PM GMT+02:00, Manuel Reimer wrote: Hello, I know that Arch is not for the "average user" and some background knowledge is expected, but this was the first time I needed a boot stick since I think at least one year. Some minutes ago I did a regular system update and after that decided to reboot. After reboot I was unable to log into my system. After fiddling a bit I rebooted to an Arch boot stick to find the following message in pacman.log: [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login installed as /etc/pam.d/system-login.pacnew As this seemed to be a candidate that may cause login problems, I deleted "system-login" and moved the ".pacnew" into place. After reboot I'm now able to log in again... IMHO something like this should not happen... Maybe it's worth a note on the Arch homepage that it is important to move this pacnew into place before reboot? Manuel
[arch-general] No login after update
Hello, I know that Arch is not for the "average user" and some background knowledge is expected, but this was the first time I needed a boot stick since I think at least one year. Some minutes ago I did a regular system update and after that decided to reboot. After reboot I was unable to log into my system. After fiddling a bit I rebooted to an Arch boot stick to find the following message in pacman.log: [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login installed as /etc/pam.d/system-login.pacnew As this seemed to be a candidate that may cause login problems, I deleted "system-login" and moved the ".pacnew" into place. After reboot I'm now able to log in again... IMHO something like this should not happen... Maybe it's worth a note on the Arch homepage that it is important to move this pacnew into place before reboot? Manuel
Re: [arch-general] How to get the app folders in Gnome?
On 21.09.19 12:51, Jesse Jaara via arch-general wrote: I've updated my laptop now, too. Again nothing at all when dropping application icons onto some other application icon... Am I doing it wrong??? Manuel You did restart gnome after updating, did you? Several times. https://gitlab.gnome.org/GNOME/gnome-shell/issues/1652 Can be worked around and works for me now Manuel
Re: [arch-general] How to get the app folders in Gnome?
On 20.09.19 14:34, Rafael Fontenelle wrote: Hello, It works here. Please check whether you have gnome-shell 1:3.34.0+94+g3d86e6e79-1 installed. Also, notice that the created app folder might move somewhere else in the list of apps: I have 8 pages of apps and the folder went to another page to keep what seems to be alphabetic order. Cheers, Rafael I have this version installed and on two user profiles dropping one application onto another does exactly nothing. I've updated my laptop now, too. Again nothing at all when dropping application icons onto some other application icon... Am I doing it wrong??? Manuel
[arch-general] How to get the app folders in Gnome?
Hello, I've updated Gnome just now. 3.34 should have the new "app folders" feature by just dragging application icons onto each other. This doesn't work for me. Is there some build error on Arch? Why is this feature missing? Thanks in advance Manuel
Re: [arch-general] How long do you make the passphrase for the private key?
On 24.06.19 18:00, mpan wrote: If you’re using a password manager, you should not care about the password being “too long”. After all it’s not you who type it. Go for 16 or 20 random chars. If the key is too complicated to remember or to type in manually, then I have to use a password manager which now saves my password to local disk again. Maybe encrypted with a master password. Then we are back at the starting problem. If someone can take my private key file, then he can also take my password manager database. How strong would you make this master password and where to save this one? A second password manager? I think if really someone takes over control over my PC, then I have to expect the password to be gone, too. I someone is really able to take my private key file, then I think he should also be able to install some kind of key logger. And I really think that finally someone *has* to come up with some replacement for this password nightmare. Some kind of hardware key maybe. I could protect the private signing key with an UUID (just call uuidgen on console). This should be pretty hard to crack but is impossible to remember so I would have to keep this written down somewhere and need this piece of paper every time I unlock the key for signing. Manuel
[arch-general] How long do you make the passphrase for the private key?
Hello, I want to publish a package repository with some packages that I need and only want to build once for all my systems. I want to make the packages available for general use. I have server space for that so I only have to rsync my final repo to my server after compiling my packages. I have my autobuild set up and signing seems to work, too. For convenience, I decided to make the passphrase not too long. I have 10 characters with both, alphanumeric and "special characters". I think if the passphrase is meant to be uncrackable alone, then we wouldn't need the big private key file, right? Is my passphrase long enough? What do the trusted users think about this topic? Thanks in advance Manuel
Re: [arch-general] Is it secure to just sign repository databases?
On 17.06.19 18:18, Eli Schwartz via arch-general wrote: That being said, it's possible to configure sudo to run makechrootpkg, but only makechrootpkg, as root. Or run SUDO_USER=... SUDO_UID=... makechrootpkg. I've tried several times to just launch makechrootpkg with root privileges directly. As makechrootpkg drops to a unprivileged user inside the chroot, this should be perfectly safe. But I always ran into errors saying that makepkg is not allowed to be run as root. Does your SUDO_USER=... SUDO_UID=... command line allow to directly launch as root without needing sudo at all? This is what I would need to make my autobuild work. Yes -- do all signing locally, after the package leaves the build VM. If something goes wrong on the VM, you can remove the relevant packages without, say, revoking your key, so the security issue is less drastic. This would also be a possible way. Sign packages where the signature is outdated, delete signatures that don't belong to packages and finally repo-add the whole stuff after deleting the db file. Is there a better tool as repo-add/repo-remove? I've been searching for some "repo-update" tool for quite a while now. A smart tool which doesn't recreate stuff and just updates a DB file would be pretty handy. Manuel
Re: [arch-general] Is it secure to just sign repository databases?
On 16.06.19 17:57, Eli Schwartz via arch-general wrote: As a matter of fact, if you use clean chroot builds then you possibly don't want to copy your private key to the chroot, and anyway there have IIRC been bugs with signing in a chroot, so the devtools scripts do not do signing in the chroot and the official upload scripts for core/extra/community will do gpg --detach--sign --no-armor by hand, so you are in good company! I don't do builds in "chroot" environment. TBH I never managed to get this to build completely automatic. The problem is that the existing scripts start off in a unprivileged context and then require me to enter the root password when entering the chroot. My own concept does it the other way around. Main script runs as root and it forks off unprivileged processes to do the build. After building this forked process exits and the "root-privileged" host process takes over again to prepare for the next package build. This includes required dependency installs. https://github.com/M-Reimer/repo-make All this runs on a dedicated "Build VM" on Oracle Virtual Box. Yes, I get "clean" builds with this, as between every build step, all unneeded dependency packages are uninstalled. Maybe there are other fully automatic systems out there, but my script served me well, so far. I was just wondering if there is any way to not have to have the private key on this build VM at all. But I guess if something goes wrong on this VM, then security is gone anyway. But thanks for the information about how the signing works. I think I'll move this out of the "unprivileged build process" and do the signing in the root-privileged main process. This way the dedicated build user of this build VM does not have access to the private key. Manuel
[arch-general] Is it secure to just sign repository databases?
Hello, I run a repository locally that I would like to share to the public. The build is mostly automated. That's why I don't want to sign each individual package. The private key is not stored on the build machine and I want to sign the resulting stuff externally. The easiest way would be actually to just manually sign the database file. As this file includes all checksums of the individual packages, I think this is as secure as signing every package, right? Thanks in advance Manuel
Re: [arch-general] How to build package in "clean chroot" using the "-U" parameter?
On 12/22/2017 03:17 PM, Giancarlo Razzolini via arch-general wrote: Well, so far you said you want to autobuild some packages and that it MUST run as root, with no good reason why. I have a set of PKGBUILD's (around 40) and a self-made "build system": http://repo-make.tuxfamily.org/ The autobuild system works completely without user interaction. You just call "repo-make" and it will do *everything* that is needed to finally have a working local repository. This is meant to be used on a dedicated build VM and never on any productive system. Now my idea was to improve this process by doing every build in a chroot environment. So far my build system does things like installing packages directly, so makepkg never has to do this as this would cause silly sudo password prompts that I don't want to have in a fully automated build. There's no reason to change the way the software gets built either. It seems to me you're trying to avoid some extra work by running everything as root. I want to avoid unnecessary work that is not needed on a system that is meant only to be used to build some packages. If I ever trash this system, I just restore the VM from a backup. If you share more of what you're trying to do, and your goals, perhaps we can help more. So far it seems like a mild XY problem. I have an existing build system that I call with root permissions and from this point on it does everything on its own. Including creating the required build user, fetching build dependencies, building packages in context of the build user, ... My idea was to make use of "chroot building" to have a clean state of packages for every build. If this is possible, I would add this. If fully automated processing doesn't work with the existing tools, I'll stick with my way and keep building without chroot. Manuel
Re: [arch-general] How to build package in "clean chroot" using the "-U" parameter?
On 12/22/2017 02:26 PM, Eli Schwartz via arch-general wrote: AFAIK this should work fine, for its intended goal. Though I don't think it gets a lot of testing. Question is: What is the intended goal. I guess it is not what I want to do? makechrootpkg elevates to root if needed, using sudo. ... which doesn't help me. My autobuild process runs as root. It also directly updates the chroot which also needs root permissions so it's the best to start with "root" and then drop privileges for the tasks that shouldn't run with root privileges. The whole system is a dedicated build VM, so there is no reason to not use "root" for the main purpose of this machine. It then has to run makepkg to update sources, *before* entering the chroot for building. That seems to be the one that works for me. That is the first time the makepkg command is run. The second time, is inside the chroot, which should automatically be run as the "builduser" user inside a systemd-nspawn container (we don't actually use chroot). And this one fails. But why? Does makechrootpkg for some reason miss to drop privileges if the "-U" parameter is used? Manuel
Re: [arch-general] How to build package in "clean chroot" using the "-U" parameter?
On 12/22/2017 02:16 PM, Óscar García Amor wrote: # su - user -c "command" In this case: # su - user -c "makechrootpkg -c -r /var/cache/PATH_TO_MY_CHROOT" Yes, of course, but then "makechrootpkg" at some point wants to call "pacman" which will fail or will cause some unwanted sudo prompt to appear. That's why I want to start with "root permissions" and only want to drop to a less privileged user for the cases where software is built.
[arch-general] How to build package in "clean chroot" using the "-U" parameter?
Hello, I want to autobuild a set of packages. For this process, it is not acceptable to use "sudo" as I don't want to enter some passwords and my autobuild program also has to do some other stuff with root privileges. The help page of "makechrootpkg" suggests, that there is an option for me: -U Run makepkg as a specified user But I tried this several times. So far without success. I've copied the PKGBUILD to the /tmp directory, just to be sure it is really readable by my build user. Then my command was: # makechrootpkg -c -U build -r /var/cache/PATH_TO_MY_CHROOT This now seems to download the source files and also is validating them against the stored MD5 sums. But after that I get the error ==> ERROR: Running makepkg as root is not allowed as it can cause permanent, catastrophic damage to your system. Seems like makepkg is called once in context of my supplied "build user" and then a second time without using the build user. Where is my mistabe? Or is this a bug in makechrootpkg? Thanks in advance Manuel
Re: [arch-general] How to build nvidia driver?
On 08/11/2017 12:20 AM, Ralf Mardorf wrote: Much likely nvidia and nvidia-dkms, however perhaps other packages. Interesting to see that there actually is a DKMS package for that. So everything, I would have to do, is to somehow get the DKMS package for the 381 driver and install it? downgrade nvidia nvidia-lts nvidia-dkms libxnvctrl nvidia-settings nvidia-utils opencl-nvidia lib32-nvidia-utils lib32-opencl-nvidia Where can I get this "downgrade" command? Manuel
[arch-general] How to build nvidia driver?
Hello, I never did this before, but on one of my systems, I'm affected by: https://devtalk.nvidia.com/default/topic/1020399/ Can someone please give me some hints about what steps I have to do to downgrade the driver without touching the kernel version? Which packages need downgrading? Thanks in advance Manuel
[arch-general] ISO broken? Unable to boot from ISO burned to DVD.
Hello, I've freshly downloaded the ISO from the Arch Linux homepage and burned with: # cdrecord dev=/dev/cdrom -dao PATH_TO_ISO Booting from this hangs with waiting for some /dev/disk/by-label/ARCH... device. After waiting for this I get to some kind of "recovery console" missing most tools. /dev/disk/by-label doesn't exist at all in this minimalistic shell. Is it possible that booting from a device "by-label" just doesn't work for a DVD drive at all? Any way to fix this? Thanks in advance Manuel
Re: [arch-general] Problem with "geoclue2" update
On 11/13/2016 06:10 PM, Ralf Mardorf wrote: Most likely nothing requires geoclue... $ pacman -Qo /usr/share/gtk-doc/html/geoclue/geoclue.devhelp2 $ pacman -Qi geoclue geoclue2 | grep "Required By" if so remove it # pacman -R geoclue This solved my problem. Thank you to everyone for the fast help. After removing "geoclue", the update of "geoclue2" worked without any problems. Manuel
[arch-general] Problem with "geoclue2" update
Hello, I am currently trying to update my system, but this fails with the following messages: geoclue2: /usr/share/gtk-doc/html/geoclue/geoclue.devhelp2 exists in filesystem geoclue2: /usr/share/gtk-doc/html/geoclue/home.png exists in filesystem geoclue2: /usr/share/gtk-doc/html/geoclue/index.html exists in filesystem geoclue2: /usr/share/gtk-doc/html/geoclue/left.png exists in filesystem geoclue2: /usr/share/gtk-doc/html/geoclue/right.png exists in filesystem geoclue2: /usr/share/gtk-doc/html/geoclue/style.css exists in filesystem geoclue2: /usr/share/gtk-doc/html/geoclue/up.png exists in filesystem Errors occurred, no packages were upgraded. Did something change in the "geoclue2" package, which causes this error? There is no announcement on the homepage... Thanks in advance Manuel
Re: [arch-general] Emacs is missing the icons in toolbar since one of the last updates
On 04/10/2016 04:24 PM, Ondřej Kučera wrote: it's already been reported: https://bugs.archlinux.org/task/48862. The same happens to me but I have the toolbar disabled in my configuration anyway, so I don't really care much. Thanks for verifying. I'll try to downgrade a few things that could cause this problem. Maybe I can track this down to just one package. Manuel
[arch-general] Since last update (yesterday) Gnome switches me to VT1 after some time
Hello, I hope someone can reproduce this one and can point me to some bug report. I'm using the closed source Nvidia driver and a default Gnome installation. Since the last update, the following happens: Usually Gnome runs two X servers. One on ":0" and one on ":1". The last one is the one, I actually use when I'm logged in. GDM keeps running on :0 (VT1). So if I press Ctrl+Alt+F1, I get back to the login screen. This exactly same configuration also applies to my laptop with an Intel GPU. Here, I also have two X servers running all the time. Since yesterday's update, after some time the first X server terminates for whatever reason. In "/var/log/Xorg.0.log", I see: [92.389] (II) systemd-logind: got resume for 13:64 [92.389] (II) systemd-logind: got resume for 13:67 [92.389] (II) systemd-logind: got resume for 13:65 [92.389] (II) systemd-logind: got resume for 13:66 [95.021] (II) systemd-logind: got pause for 226:0 [95.021] (II) systemd-logind: got pause for 13:64 [95.021] (II) systemd-logind: got pause for 13:67 [95.021] (II) systemd-logind: got pause for 13:65 [95.021] (II) systemd-logind: got pause for 13:66 [ 405.532] (II) evdev: Sun USB Keyboard: Close [ 405.532] (II) UnloadModule: "evdev" [ 405.532] (II) systemd-logind: releasing fd for 13:65 [ 405.546] (II) evdev: USB Mouse: Close [ 405.546] (II) UnloadModule: "evdev" [ 405.546] (II) systemd-logind: releasing fd for 13:64 [ 405.567] (II) evdev: Power Button: Close [ 405.567] (II) UnloadModule: "evdev" [ 405.567] (II) systemd-logind: releasing fd for 13:66 [ 405.593] (II) evdev: Power Button: Close [ 405.593] (II) UnloadModule: "evdev" [ 405.593] (II) systemd-logind: releasing fd for 13:67 [ 405.634] (II) NVIDIA(GPU-0): Deleting GPU-0 [ 405.857] (II) Server terminated successfully (0). Closing log file. This wouldn't be a problem, as logging out restarts this X server allowing me to log in again. The problem is, that this X server termination switches the virtual terminal, so it brings me back to VT1 and I have to switch back to VT2 manually. Does anyone have any idea how to fix this? One possible solution for a (temporary) fix could be if there is any way to ask GDM somehow to immediately terminate this X server on VT1 after logging in. Thanks in advance Manuel
[arch-general] Emacs is missing the icons in toolbar since one of the last updates
Hello, is this a known bug or do only I have this issue? Since the last system update, I no longer have any icons in emacs. The toolbar is just empty. Thanks in advance. Manuel
Re: [arch-general] Why does a regular user have access to /dev/uinput (and why only temporary)
I've been searching a little more and found it: https://bugs.archlinux.org/task/47995 On 02/02/2016 06:41 PM, Manuel Reimer wrote: Hello, I'm currently developing a usermode input driver using uinput. While doing this, I've found some "ugly" behaviour. If I do getfacl from my regular user, I get: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- group::--- mask::rw- other::--- So for whatever reason my user is able to launch a usermode input driver. No root permission needed. But in fact the driver isn't even loaded (no uinput module). But it is loaded as soon as I try to access the device. After that, I have: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw-#effective:--- group::--- mask::--- other::--- So somehow the permission is still there, but no longer effective??? If I switch VT once (and probably switching the active session this way) I have permission again and now my user keeps it. What is causing this ugly behaviour? Why does a user have to have uinput permissions at all? The (possible security) problem with this is, that the driver (may be a simulated keyboard driver) keeps active even if the session changes. So a software, launched in one session, affects another session. Thanks in advance Manuel
[arch-general] Why does a regular user have access to /dev/uinput (and why only temporary)
Hello, I'm currently developing a usermode input driver using uinput. While doing this, I've found some "ugly" behaviour. If I do getfacl from my regular user, I get: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- group::--- mask::rw- other::--- So for whatever reason my user is able to launch a usermode input driver. No root permission needed. But in fact the driver isn't even loaded (no uinput module). But it is loaded as soon as I try to access the device. After that, I have: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- #effective:--- group::--- mask::--- other::--- So somehow the permission is still there, but no longer effective??? If I switch VT once (and probably switching the active session this way) I have permission again and now my user keeps it. What is causing this ugly behaviour? Why does a user have to have uinput permissions at all? The (possible security) problem with this is, that the driver (may be a simulated keyboard driver) keeps active even if the session changes. So a software, launched in one session, affects another session. Thanks in advance Manuel
[arch-general] First try to go to KDE 5.5
Hello, today, I tried to update my laptop to KDE 5.5. The first problem, I've found, is, that it seems to be impossible to configure SDDM. The option is there in "System Settings", but nothing opens. Then, I connected my TV screen to the HDMI port of my laptop and tried dual-screen setup. At first this seemed to work well, but for some reason *every* window now opens on my TV. The laptop screen was set to be default, so this is not the reason. I configured the laptop screen to be turned off when the lid is closed. If I do this, then the laptop screen keeps black if the lid is opened again. If I lock the screen in this case and unlock after that, then the screen turns on, but the taskbar seems to be crashed. This is just a short list of bugs, I found, before uninstalling Plasma 5. Does someone here have similar problems? As KDE 4 also had many bugs, I learned to deal with, as they never got fixed, and KDE 5 doesn't seem to be much better, I now give Gnome a try... Manuel
[arch-general] Since last systemd update dhcpcd no longer updates resolv.conf
Hello, since the last systemd update I have to systemctl restart dhcpcd@... every time I boot my system. What do I have to do to get sure that dhcpcd updates /etc/resolv.conf on the first time? Thanks in advance Manuel
Re: [arch-general] pacman security when importing new keys?
On 02/12/2015 03:46 AM, Genes Lists wrote: Just FYI in case anyone else gets flaky behaviour. Be interesting to know for those that said 'n' to the import - if they got asked a second time or not. Yes, you get asked a second time. Manuel
[arch-general] pacman security when importing new keys?
Hello, today, pacman asked me to import a new signature key. So far this was done automatically using a keys-package, which, itself, was signed with a trusted key. How is the new mechanism secured? Is the new way, to bring keys to users, prone to MITM attacks? Thanks in advance. Manuel
Re: [arch-general] Firefox 33, Intel GPU and latest flashplayer: No animations but white area.
Thanks for verifying the bug. I've downloaded Firefox 33.1 from the Mozilla FTP servers (binary package) and this build works well on my laptop. This means that the Arch Linux package somehow is broken. I've opened a bug for this: https://bugs.archlinux.org/task/42743 Greetings, Manuel On 10/18/2014 05:19 PM, A Rojas wrote: Manuel Reimer wrote: Hello, can someone reproduce the following on an Intel GPU with Firefox 33 and Flash? If I open a website with Flash media, then the plugin loads (the context menu is the one that gets created by Adobe Flash) but I can't see anything. The area, where the animation should be is just white. I've downgraded to the latest Firefox 32 and my Flash content immediately worked again. Am I the only one with this problem or can someone reproduce this? Thanks in advance. Greetings, Manuel Same here, also on Intel
[arch-general] Firefox 33, Intel GPU and latest flashplayer: No animations but white area.
Hello, can someone reproduce the following on an Intel GPU with Firefox 33 and Flash? If I open a website with Flash media, then the plugin loads (the context menu is the one that gets created by Adobe Flash) but I can't see anything. The area, where the animation should be is just white. I've downgraded to the latest Firefox 32 and my Flash content immediately worked again. Am I the only one with this problem or can someone reproduce this? Thanks in advance. Greetings, Manuel
[arch-general] Kernel updated to 3.14.5-1. Now my Lenovo IdeaPad hangs on boot...
Hello, I use gummiboot to boot my Notebook. So far all kernel updates worked well and I never got any problems, but for some reason the update to 3.14.5 now causes my system to no longer boot up. Can someone help me to find the reason for the problem and to get my Notebook to boot up again? Thanks in advance. Greetings, Manuel
Re: [arch-general] Kernel updated to 3.14.5-1. Now my Lenovo IdeaPad hangs on boot...
On 06/03/2014 05:16 PM, Anatol Pomozov wrote: To recover your machine: 1) Boot from Arch ISO. I always have an USB pan with Arch image and found it useful for emergency cases. 2) Find your system partitions. Use 'lsblk' for this 3) mount your system partition, e.g. 'mkdir system; mount /dev/sda1 system' 4) arch-chroot into your system: 'arch-chroot system' 5) fix your system e.g. downgrade kernel to previous version 'downgrade linux' 6) reboot and enjoy Did so, now. Now I'm on 3.14.4, again. System boots without any problems. But why can't I use the current kernel? Does someone here successfully boot 3.14.5 via efistub? Bug in kernel? Or maybe bug in kernel configuration? Greetings, Manuel
Re: [arch-general] Kernel updated to 3.14.5-1. Now my Lenovo IdeaPad hangs on boot...
On 06/03/2014 05:11 PM, André Vitor wrote: Try booting in legacy/bios mode. Inside system, try just recompiling kernel from official pkgbuild. In my HP laptop, some kernels just refuses to boot in UEFI mode, hanging in kernel loading (directly or from any bootloader, as refind). Recompiling kernel or downgrading to previous working fix the issue. That's the first time, I have issues like this on my laptop. But thanks to all for the help. Downgrading did the trick and I hope that the next kernel will work again... Greetings, Manuel
[arch-general] Security vulnerability (CVE-2014-0004) in udisks/udisks2
Hello, I already flagged the packages out of date, but maybe other people are interested, too, that there is a known security hole in udisks/udisks2, which has been fixed upstream with new releases: http://lists.freedesktop.org/archives/devkit-devel/2014-March/001568.html Greetings, Manuel
Re: [arch-general] Security vulnerability (CVE-2014-0004) in udisks/udisks2
Jelle van der Waa jelle at vdwaa.nl writes: FYI: https://mailman.archlinux.org/pipermail/arch-dev-public/2014- March/025952.html Thank you for this information. Am I allowed to ask gmane.org to add this list to their archive? This would really help me to get access to this list. Greetings, Manuel
Re: [arch-general] Security vulnerability (CVE-2014-0004) in udisks/udisks2
Thomas Bächler thomas at archlinux.org writes: I quickly went over to gmane and requested subscription of arch-security to gmane, so there is nothing left but to wait. I hope you didn't request readonly as, if I'm registered to the list with the mail address, I use from the gmane webinterface, it is possible to post to, for example, the general list. This posting is written using the gmane webinterface and in many cases I don't have access to my private mail, so having access to a list via webinterface can be very handy. Greetings, Manuel
[arch-general] vi just terminates on a 32bit machine
Hello,
if I access one of my systems via ssh and try to use vi there, then
it immediately returns with exit status 1.
System is an up-to-date 32bit ArchLinux system.
I've attached the strace output of my try to run vi to this mail.
Can someone see there what could have happened? Reinstalling vi didn't
fix this for me...
Thank you very much in advance
Yours
Manuel
execve(/usr/bin/vi, [vi], [/* 17 vars */]) = 0
brk(0) = 0x924a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77b3000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=31071, ...}) = 0
mmap2(NULL, 31071, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77ab000
close(3)= 0
open(/usr/lib/libncursesw.so.5, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\276\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=355820, ...}) = 0
mmap2(NULL, 360292, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7753000
mmap2(0xb77a8000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x54000) = 0xb77a8000
close(3)= 0
open(/usr/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \231\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=2005327, ...}) = 0
mmap2(NULL, 1759844, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb75a5000
mmap2(0xb774d000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a8000) = 0xb774d000
mmap2(0xb775, 10852, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb775
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb75a4000
set_thread_area({entry_number:-1 - 6, base_addr:0xb75a46c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb774d000, 8192, PROT_READ) = 0
mprotect(0xb77a8000, 8192, PROT_READ) = 0
mprotect(0x807b000, 4096, PROT_READ)= 0
mprotect(0xb77d5000, 4096, PROT_READ) = 0
munmap(0xb77ab000, 31071) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
getpid()= 378
rt_sigaction(SIGHUP, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, {0x8058590, [], SA_RESTART}, {SIG_IGN, [], SA_RESTART}, 8)
= 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGXFSZ, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {0x8058590, [], SA_RESTART}, {SIG_IGN, [], SA_RESTART},
8) = 0
open(/usr/lib/locale/locale-archive, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=350032, ...}) = 0
mmap2(NULL, 350032, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb754e000
close(3)= 0
mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77ab000
brk(0) = 0x924a000
rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTSTP, {0x8056d90, [], SA_RESTART}, {SIG_IGN, [], SA_RESTART},
8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigaction(SIGINT, {0x8057080, [], SA_RESTART}, {SIG_IGN, [], SA_RESTART}, 8)
= 0
rt_sigaction(SIGTSTP, {0x8056d90, [], SA_RESTART}, {0x8056d90, [], SA_RESTART},
8) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
stat64(/root/.terminfo, 0xbfea3ff0) = -1 ENOENT (No such file or directory)
stat64(/usr/share/terminfo, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(/usr/share/terminfo/x/xterm, R_OK) = 0
open(/usr/share/terminfo/x/xterm, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=3270, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb754d000
read(3, \32\0010\0\0\17\0\235\1l\5xterm|xterm terminal..., 4096) = 3270
read(3, , 4096) = 0
close(3)= 0
munmap(0xb754d000, 4096)= 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ,
[arch-general] Broken pipe messages while last archlinux keyring update
Hello, with the last update of the Archlinux keyring package, I got a few errors like the following one: usr/bin/pacman-key: line 615: printf: write error: Broken pipe Is this a known bug or can this be ignored? Yours Manuel Reimer
[arch-general] Can't build virtualbox
Hello, I have a reproducible problem with virtualbox on my system. To find out which version was the first one that causes those problems for me, I want to build virtualbox on my own and step back until the problem no longer exists. I've checked out the community PKGBUILD's using git. If I try to build virtualbox, it always ends with the following messages: kmk_builtin_rm -f /home/build/git/community/virtualbox/repos/community-x86_64/src/VirtualBox-4.2.6/out/linux.amd64/release/obj/webservice/gsoap_copy_all_ts kmk_builtin_mkdir -p /home/build/git/community/virtualbox/repos/community-x86_64/src/VirtualBox-4.2.6/out/linux.amd64/release/obj/webservice/demo_soapxml /home/build/git/community/virtualbox/repos/community-x86_64/src/VirtualBox-4.2.6/out/linux.amd64/release/obj/webservice/demo_headers /home/build/git/community/virtualbox/repos/community-x86_64/src/VirtualBox-4.2.6/out/linux.amd64/release/obj/webservice/demo_namespacemaps kmk_builtin_mv -f /home/build/git/community/virtualbox/repos/community-x86_64/src/VirtualBox-4.2.6/out/linux.amd64/release/obj/webservice/demo_headers usage: kmk_builtin_mv [-f | -i | -n] [-v] source target or: kmk_builtin_mv [-f | -i | -n] [-v] source ... directory or: kmk_builtin_mv --help or: kmk_builtin_mv --version kmk: *** [/home/build/git/community/virtualbox/repos/community-x86_64/src/VirtualBox-4.2.6/out/linux.amd64/release/obj/webservice/gsoap_copy_all_ts] Error 64 kmk: *** Waiting for unfinished jobs info: soapC-1.cpp info: soapC-2.cpp info: soapC-3.cpp info: soapC-4.cpp info: soapC-5.cpp info: soapC-6.cpp info: soapC-7.cpp info: soapC-8.cpp info: soapC-9.cpp info: soapC-10.cpp info: soapC-11.cpp info: soapC-12.cpp info: soapC-13.cpp info: soapC-14.cpp info: soapC-15.cpp info: soapC-16.cpp info: soapC-17.cpp info: soapC-18.cpp info: soapC-19.cpp info: soapC-20.cpp split-soapC: Created 20 files. kmk: *** Exiting with status 2 == ERROR: A failure occurred in build(). Aborting... I'm building with -j2. Can someone please tell me what I have to do to make the build succeed? Thanks in advance Yours Manuel
Re: [arch-general] SeaMonkey outdated. Critical security holes in the current version!
Paul Marwick wrote: If you're concerned, you could do what I do - download the build information from the ABS and build it yourself. A bit of minor editing of the PKGBUILD is required, and the build takes a while (around and hour twenty minutes on my CoreDuo laptop), but that is it... Sorry, but that's not the way how things should work. If a distribution offers a package, then it should also offer updates for it. Most users don't monitor all the packages, a distribution offers, for possible holes. They just trust their distributor to ship security updates on time. As long as you have the SeaMonkey package one of your primary repositories, you also signal to users, that you plan to update this package. If you can't keep it updated, please drop it and, for example, tell your users to switch to Firefox and Thunderbird. Bad reaction time on security holes was one of the top reasons, why I ported from Slackware to Archlinux and now it seems like Archlinux isn't much better there... Yours Manuel
[arch-general] SeaMonkey outdated. Critical security holes in the current version!
Hello Archlinux team, the SeaMonkey package is outdated. Many critical issues have been fixed in the current version: http://www.mozilla.org/security/known-vulnerabilities/seamonkey.html So in my opinion a fixed package is required as soon as possible. As SeaMonkey contains a browser component and there may be people who use this to surf the internet, in my opinion new versions should be packaged with the same priority as Firefox packages. The only alternative would be to drop the package at all. Yours Manuel Reimer
