SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Oh, this is getting absurd! How many new kernels is that in the space of a week?
So.... what hidden nasties does this one fix I wonder....
Thanks for the heads-up cwiz.
My thoughts exactly. Do they always release stable kernels this often? I just built 4.4.27 and then 4.4.28. I'm thinking I will stick with 4.4.28 unless some other important issue comes to light.
My thoughts exactly. Do they always release stable kernels this often? I just built 4.4.27 and then 4.4.28. I'm thinking I will stick with 4.4.28 unless some other important issue comes to light.
I decided to build and install 4.8.6 anyway as there were a number of drm/i915 and iwlwifi fixes and my machine contains both of those components.
I did notice this one however:
Code:
commit ea288a690cc4e53a528ae6a1d37cd6e14320ed27
Author: Jan Kara <jack@suse.cz>
Date: Mon Sep 19 17:39:09 2016 +0200
posix_acl: Clear SGID bit when setting file permissions
commit 073931017b49d9458aa351605b43a7e34598caef upstream.
When file permissions are modified via chmod(2) and the user is not in
the owning group or capable of CAP_FSETID, the setgid bit is cleared in
inode_change_ok(). Setting a POSIX ACL via setxattr(2) sets the file
permissions as well as the new ACL, but doesn't clear the setgid bit in
a similar way; this allows to bypass the check in chmod(2). Fix that.
References: CVE-2016-7097
To be able to chmod in the first place one would have to be the owner of the file. Being the owner of a file that is both SGID and owned by a group you're not a member of seems like an unlikely situation, and I'm not sure quite what this 'check' in chmod(2) is actually trying to prevent, or what bypassing it would buy you. Maybe I'm just not devious enough to see it though.
mutt 1.7.1 is released. Also, I'd like to request it be compiled with --enable-sidebar if possible. This is a new feature that was added in version 1.7.0.
Last edited by montagdude; 11-01-2016 at 07:46 PM.
I would like to request some support for urxvt, useful even if just remotely accessing a Slackware system from a urxvt terminal.
This is something that occationally trips me up. But even if you don't have root on the box you're accessing you can put the terminfo files in ~/.terminfo/`echo $TERM/ | cut -b 1`/$TERM
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.