Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote: > It's not like libcap is a big dependency true, but not everyone needs this, nor can everyone leverage it (caps). it's a linux-centric implementation and is dependent upon filesystem support being available & enabled. that doesn't entirely justify making it a USE flag (since the code already has runtime fallback logic for when the fs doesn't support things), but since the USE is low overhead and leverages logic that already has to be there, i have no problem keeping it. plus it defaults to on. > and it's not like this is an > attempt to make the system more secure by according just the privileges > needed for apps to work as intended, right ? mmm that's exactly what this is > If the USE flag must stay, how is it different that current caps USE > flag ? It applies and not just enables support but is that relevant to > the purpose at hand ? USE=caps is for apps to control their runtime privs (there's also packages which want to query things like coreutils, but let's ignore those). in order to grant themselves reduced privs, they have to start with them in the first place -- capabilities allows you to remove privs from yourself, not extend them. that's accomplished (classically & today) by having the program set*id. thus, when the program is run, it is (typically) launched as the root user which means they have the full capset. if the package supports USE=caps, then it means the program is intelligent enough to know what capabilities it needs and so it can drop all of the rest before executing the main body of code. if it doesn't support USE=caps, then it either tries to do all the superuser stuff first and then drop its uid back down to the executing user's. if it can't do that, then it has to be super careful about everything it does. some packages (like openssh and Google Chrome -- not great examples, but good enough) implement even more complicated setups with privilege separation where there is IPC between a privileged process and an unprivileged one. either way, obviously the more code you have, the harder it is to make sure you get it right (and history is littered with vulns where people didn't). so wouldn't it be nice if you could set the required capabilities on a binary and drop the set*id entirely ? that's what USE=filecaps gets us. now there is no time frame within which you can attack and gain elevated privileges -- the kernel will have the new program start off with the right capset from the very beginning. obviously i'm glossing over bugs where people can get get a program to do things it shouldn't with the capset it didn't drop, but that scenario exists regardless of set*id and USE=caps behavior. in the ideal world: - USE=filecaps so you start only with the caps you need - not be set*id at all - do all the things at the very beginning that require the elevated caps - support USE=caps so you can then drop all of your elevated caps - run like normal and process all user input as an example, let's look at ping. we give it set*id because people want to be able to do something innocuous as `ping 192.168.0.1` w/out `sudo` first. in order to send ICMP_ECHO packets, it needs to create a SOCK_RAW socket which the kernel doesn't allow random users to create (otherwise they could generate arbitrary packets on the network). when USE=-cap, the first thing ping does is create the socket, then drop the root uid. when USE=cap, the first thing it does is drop all of its permitted caps to the bare min what it needs in the future, and then sets the effective even lower. when it needs to open the socket, it sets the effective to what it needs, opens the socket, and then sets the effective lower again. rinse/repeat. at least, this is all my understanding of things. i could be completely wrong, so feel free to correct something if you notice it. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
Nuno J. Silva posted on Fri, 25 Jan 2013 22:06:35 +0200 as excerpted: > I am almost sure the current check does *not* use config.gz but > /usr/src/linux/.config. At least, I've not had config.gz enabled for a > long time, and I've always seen the checks working. In fact, I think the > checks print something along the lines of "looking for kernel source > under /usr/src/linux... found config for linux-...". Actually, AFAIK the current check looks for both config.gz and in the kernel sources dir, since often one or the other isn't available, but a lot of the time one or the other /is/ available, as well. (The kernel can be configured without config.gz, and the sources symlink might be stale and point to something not installed any more, or maybe the partition containing the sources isn't mounted, or maybe the sources dir is there but belongs to a user other than portage or root, with permissions such that portage can't access it.) So the current check is for whichever one it can find. I don't know which it checks first and whether it checks both if the first is there but comes up with a problem, but if one is there and not the other, it should properly find and use the one, regardless of which one it is. (Of course the checks are in the eclass. Anyone sufficiently curious could just go look to see what it did.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
On 26/01/2013 01:10, Gilles Dartiguelongue wrote: > If the USE flag must stay, how is it different that current caps USE > flag ? It applies and not just enables support but is that relevant to > the purpose at hand ? filecaps require the kernel to support security xattrs on the filesystems used for install (and merge, iirc, not sure if the eclass works this around — at the time it was written, tmpfs didn't support xattr; now it does so it does support filecaps), and the filesystem-based capabilities as well (which might be forced-on right now but I'm not going to bet on it). E.g.: CONFIG_EXT4_FS_XATTR=y CONFIG_TMPFS_XATTR=y -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
This might be a silly question already answered in a previous thread, but why make it filecaps a USE-enable capability at all ? It's not like libcap is a big dependency and it's not like this is an attempt to make the system more secure by according just the privileges needed for apps to work as intended, right ? If the USE flag must stay, how is it different that current caps USE flag ? It applies and not just enables support but is that relevant to the purpose at hand ? -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
most settings are now defaults
-mike
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: fcaps.eclass
# @MAINTAINER:
# Constanze Hausner
# base-sys...@gentoo.org
# @BLURB: function to set POSIX file-based capabilities
# @DESCRIPTION:
# This eclass provides a function to set file-based capabilities on binaries.
#
# Due to probable capability-loss on moving or copying, this happens in
# pkg_postinst-phase (at least for now).
#
# @EXAMPLE:
# You can manually set the caps on ping and ping6 by doing:
# @CODE
# pkg_postinst() {
# fcaps cap_net_raw bin/ping bin/ping6
# }
# @CODE
#
# Or set it via the global ebuild var FILECAPS:
# @CODE
# FILECAPS=(
# cap_net_raw bin/ping bin/ping6
# )
# @CODE
if [[ ${___ECLASS_ONCE_FCAPS} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_FCAPS="recur -_+^+_- spank"
IUSE="+filecaps"
DEPEND="filecaps? ( sys-libs/libcap )"
# @ECLASS-VARIABLE: FILECAPS
# @DEFAULT_UNSET
# @DESCRIPTION:
# An array of fcap arguments to use to automatically execute fcaps. See that
# function for more details.
#
# All args are consumed until the '--' marker is found. So if you have:
# @CODE
# FILECAPS=( moo cow -- fat cat -- chubby penguin )
# @CODE
#
# This will end up executing:
# @CODE
# fcaps moo cow
# fcaps fat cat
# fcaps chubby penguin
# @CODE
#
# Note: If you override pkg_postinst, you must call fcaps_pkg_postinst yourself.
# @FUNCTION: fcaps
# @USAGE: [-o ] [-g ] [-m ]
# @DESCRIPTION:
# Sets the specified capabilities on the specified files.
#
# The caps option takes the form as expected by the cap_from_text(3) man page.
# If no action is specified, then "=ep" will be used as a default.
#
# If the file is a relative path (e.g. bin/foo rather than /bin/foo), then the
# appropriate path var ($D/$ROOT/etc...) will be prefixed based on the current
# ebuild phase.
#
# If the system is unable to set capabilities, it will use the specified user,
# group, and mode (presumably to make the binary set*id). The defaults there
# are root:root and 4711. Otherwise, the ownership and permissions will be
# unchanged.
fcaps() {
debug-print-function ${FUNCNAME} "$@"
# Process the user options first.
local owner='root'
local group='root'
local mode='4711'
while [[ $# -gt 0 ]] ; do
case $1 in
-o) owner=$2; shift;;
-g) group=$2; shift;;
-m) mode=$2; shift;;
*) break;;
esac
shift
done
[[ $# -lt 2 ]] && die "${FUNCNAME}: wrong arg count"
local caps=$1
[[ ${caps} == *[-=+]* ]] || caps+="=ep"
shift
local root
case ${EBUILD_PHASE} in
compile|install|preinst)
root=${ED:-${D}}
;;
postinst)
root=${EROOT:-${ROOT}}
;;
esac
# Process every file!
local file out
for file ; do
[[ ${file} != /* ]] && file="${root}${file}"
if use filecaps ; then
# Try to set capabilities. Ignore errors when the
# fs doesn't support it, but abort on all others.
debug-print "${FUNCNAME}: setting caps '${caps}' on
'${file}'"
if ! out=$(LC_ALL=C setcap "${caps}" "${file}" 2>&1) ;
then
if [[ ${out} != *"Operation not supported"* ]]
; then
eerror "Setting caps '${caps}' on file
'${file}' failed:"
eerror "${out}"
die "could not set caps"
else
local fstype=$(stat -f -c %T "${file}")
ewarn "Could not set caps on '${file}'
due to missing filesystem support."
ewarn "Make sure you enable XATTR
support for '${fstype}' in your kernel."
fi
else
# Sanity check that everything took.
setcap -v "${caps}" "${file}" >/dev/null \
|| die "Checking caps '${caps}' on
'${file}' failed"
# Everything worked. Move on to the next file.
continue
fi
fi
# If we're still here, setcaps failed.
debug-print "${FUNCNAME}: setting owner/mode on '${file}'"
chown "${owner}:${group}" "${file}" || die
chmod ${mode} "${file}" || die
done
}
# @FUNCTION: fcaps_pkg_postinst
# @DESCRIPTION:
# Proces
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, Jan 25, 2013 at 3:06 PM, Nuno J. Silva wrote: > Well, we could also get rid of issues with clashing USE flags by getting > rid of USE flags and offering monolithic binary packages with almost > every compatible feature enabled by default. I'm not suggesting that we get rid of options - only that we have simplified ones for those who don't need them. You can get all the benefits of Gentoo without tweaking every other kernel parameter. That's no different from having a desktop profile/etc. The value of Gentoo is the /ability/ to tweak anything and everything, not the /necessity/ to do so. We already offer genkernel - why not a package that basically runs it with a more comprehensive configuration and installs the kernel? Rich
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 2013-01-25, Rich Freeman wrote: > On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva wrote: >> >> Sorry, what's the difference between cheching =y and =m? I thought those >> were both part of the kernel config... > > I'm talking about /proc/config.gz, which only reflects .config at the > time that the kernel was built. So, build with config=n, then set > config=m and install the modules but don't replace the kernel. Now > /proc/config.gz still says n, but the module is there and works fine. > And this is in fact the easiest way to add a module for something that > you didn't realize you needed at kernel build time - you can do this > on a running system. > >> >>> You can also check /usr/src/linux/.config, but the sources might not >>> correspond to the running kernel, or the kernel on the next reboot, or >>> whatever. >> >> Ok, what do these checks do right now? I thought that they were checking >> .config... > > I dunno. I wasn't talking about how the current config checks work. > The question was whether it was possible to determine how the kernel > was configured - I was answering in general. I am almost sure the current check does *not* use config.gz but /usr/src/linux/.config. At least, I've not had config.gz enabled for a long time, and I've always seen the checks working. In fact, I think the checks print something along the lines of "looking for kernel source under /usr/src/linux... found config for linux-...". >> So you're saying that it's perfectly OK to check for =y or =n, but that >> it's somehow more difficult to check for =m? > > My previous paragraph was referring to checking config.gz - and that > is unreliable for modules. /usr/src/linux/.config is unreliable for > the reason I stated in the next paragraph - it doesn't necessarily > reflect the running kernel. Not only for modules, config.gz may not even be available, while /usr/src/linux/.config is reliable, as it should exist, and, when you're compiling, you're typically compiling for what is going to be your main kernel, the one under /usr/src/linux, which, to have been built, must have a .config, an. And you do not want to check against the running kernel, you want to check against the currently selected kernel. Checking /proc/config.gz would lead to issues when you're in middle of a kernel update and rebuilding modules before reboot. >> This won't even solve the issue, even if some people may actually prefer >> a pre-built kernel. > > Depends on the issue. There isn't just one issue under discussion in > this thread. A fairly bulletproof kernel solves a lot of issues in > general as it can have newbie-safe defaults (like just about anything > in any config check). There is a reason that most distros don't need > config checks. Well, we could also get rid of issues with clashing USE flags by getting rid of USE flags and offering monolithic binary packages with almost every compatible feature enabled by default. And newbie-safe, I've had far too many systems where your usual binary distro "newbie-safe" kernel fails and the first thing I need to do even with binary distros is to build my own kernel to get something that actually boots with no issues. >> But, definitely, fatal checks should not be a default, there are way too >> many scenarios. > > Yup - just trying to point out some of the perils. As I said there > are lots of 80% solutions. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva wrote: > > Sorry, what's the difference between cheching =y and =m? I thought those > were both part of the kernel config... I'm talking about /proc/config.gz, which only reflects .config at the time that the kernel was built. So, build with config=n, then set config=m and install the modules but don't replace the kernel. Now /proc/config.gz still says n, but the module is there and works fine. And this is in fact the easiest way to add a module for something that you didn't realize you needed at kernel build time - you can do this on a running system. > >> You can also check /usr/src/linux/.config, but the sources might not >> correspond to the running kernel, or the kernel on the next reboot, or >> whatever. > > Ok, what do these checks do right now? I thought that they were checking > .config... I dunno. I wasn't talking about how the current config checks work. The question was whether it was possible to determine how the kernel was configured - I was answering in general. > > So you're saying that it's perfectly OK to check for =y or =n, but that > it's somehow more difficult to check for =m? My previous paragraph was referring to checking config.gz - and that is unreliable for modules. /usr/src/linux/.config is unreliable for the reason I stated in the next paragraph - it doesn't necessarily reflect the running kernel. > This won't even solve the issue, even if some people may actually prefer > a pre-built kernel. Depends on the issue. There isn't just one issue under discussion in this thread. A fairly bulletproof kernel solves a lot of issues in general as it can have newbie-safe defaults (like just about anything in any config check). There is a reason that most distros don't need config checks. > But, definitely, fatal checks should not be a default, there are way too > many scenarios. Yup - just trying to point out some of the perils. As I said there are lots of 80% solutions. Rich
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 2013-01-25, Rich Freeman wrote: > On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva wrote: >> Is there any syntax to check if something is either disabled or built as >> a module? > > Very problematic. What is built in for the currently running kernel > can be fairly reliably determined by grepping /proc/config.gz - IF > support for that was enabled in the kernel. But, there is no > guarantee that this kernel will be running on the next boot. > Determining what is build as a module really requires interpreting the > contents of /lib/modules - a module could have been built after the > kernel was built, in which case /proc/config.gz might indicate no > support even though it is supported. I don't think DEVTMPFS can be > made a module, however (not sure on that). Sorry, what's the difference between cheching =y and =m? I thought those were both part of the kernel config... > You can also check /usr/src/linux/.config, but the sources might not > correspond to the running kernel, or the kernel on the next reboot, or > whatever. Ok, what do these checks do right now? I thought that they were checking .config... So you're saying that it's perfectly OK to check for =y or =n, but that it's somehow more difficult to check for =m? > It really is a touchy situation, hence all the emails in the thread. > You can build something that will work OK 80% of the time though by > checking the source tree. I am not taking about introducing a different way to check, just asking if there is a way to make the broadcom-sta check a bit more realistic. > Part of me wonders if we should just ship a binary kernel/initramfs as > an option. Then again, users could just use genkernel and get > something like that anyway. My main issue with genkernel is that its > default options are focused more on the install CD than ordinary use - > things like tuners/multimedia/lirc and the like tend to not be > enabled. I would think a typical desktop-oriented distro is going to > enable as a module anything that doesn't cause breakage. This won't even solve the issue, even if some people may actually prefer a pre-built kernel. It would be a bit more realistic to perform checks against *all* the kernels under /usr/src/linux, in a non-fatal way, of course. This would still generate lots of noise, but would produce a more useful output, like: | net-wireless/broadcom-sta - The following issues were found: | | Option CONFIG_B43 cannot be built-in, but was found to be built-in in | the following kernels : | | - linux-2.6.30-gentoo-r5 | - linux-2.6.34-gentoo-r6 | - linux-3.2.1-gentoo-r2 Or maybe have a dedicated directory to store .config's portage should check against, and check only against these. But, definitely, fatal checks should not be a default, there are way too many scenarios. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-dev] Confusing tmpfs information in udev news item
El vie, 25-01-2013 a las 14:22 -0500, Rich Freeman escribió: > On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos wrote: > > Does it apply to /dev/shm? That is the line I have in my fstab: > > shm /dev/shmtmpfs > > nodev,nosuid,noexec 0 0 > > No. It applies ONLY to /dev - if you even have a /dev line, and if > you don't that is OK. > > Rich > > Fine, thanks a lot! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, Jan 25, 2013 at 2:19 PM, Christopher Head wrote: > Surely even that isn’t good enough, since the user could have built an > option as a module, tested it out, discovered it worked fine, and then > rebuilt the kernel with the option set to Y, but the .ko file would > still be left lying around? Yup. Until the day comes when we have a USE flag for every kernel parameter (in both built-in and module form) and just have the ebuild actually build and install the kernel, it is going to be messy. The kernel is a bit unique in that we just dump a pile of source on the disk and ask the user to have at it. Note that I'm by no means advocating that we actually do any of that - the kernel is unusual in that it is EXTREMELY configurable otherwise this is probably what would have been done. As I mentioned in my last email maybe having a kernel package that does do exactly that for a desktop-oriented kernel with maybe only a few USE options might not be a bad idea - perhaps even managing grub config and all. That could be something that would make life easier on users who don't care to customize their kernels. Rich
Re: [gentoo-dev] Confusing tmpfs information in udev news item
On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos wrote: > Does it apply to /dev/shm? That is the line I have in my fstab: > shm /dev/shmtmpfs > nodev,nosuid,noexec 0 0 No. It applies ONLY to /dev - if you even have a /dev line, and if you don't that is OK. Rich
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, 25 Jan 2013 13:47:05 -0500 Rich Freeman wrote: > Very problematic. What is built in for the currently running kernel > can be fairly reliably determined by grepping /proc/config.gz - IF > support for that was enabled in the kernel. But, there is no > guarantee that this kernel will be running on the next boot. > Determining what is build as a module really requires interpreting the > contents of /lib/modules - a module could have been built after the > kernel was built, in which case /proc/config.gz might indicate no > support even though it is supported. I don't think DEVTMPFS can be > made a module, however (not sure on that). Surely even that isn’t good enough, since the user could have built an option as a module, tested it out, discovered it worked fine, and then rebuilt the kernel with the option set to Y, but the .ko file would still be left lying around? Chris
[gentoo-dev] Confusing tmpfs information in udev news item
I got today the udev news item and found: - "The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)" Does it apply to /dev/shm? That is the line I have in my fstab: shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva wrote: > Is there any syntax to check if something is either disabled or built as > a module? Very problematic. What is built in for the currently running kernel can be fairly reliably determined by grepping /proc/config.gz - IF support for that was enabled in the kernel. But, there is no guarantee that this kernel will be running on the next boot. Determining what is build as a module really requires interpreting the contents of /lib/modules - a module could have been built after the kernel was built, in which case /proc/config.gz might indicate no support even though it is supported. I don't think DEVTMPFS can be made a module, however (not sure on that). You can also check /usr/src/linux/.config, but the sources might not correspond to the running kernel, or the kernel on the next reboot, or whatever. It really is a touchy situation, hence all the emails in the thread. You can build something that will work OK 80% of the time though by checking the source tree. Part of me wonders if we should just ship a binary kernel/initramfs as an option. Then again, users could just use genkernel and get something like that anyway. My main issue with genkernel is that its default options are focused more on the install CD than ordinary use - things like tuners/multimedia/lirc and the like tend to not be enabled. I would think a typical desktop-oriented distro is going to enable as a module anything that doesn't cause breakage. Rich
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 2013-01-22, Robin H. Johnson wrote: > I'm raising this patch because of the recent spate of bugs with the > latest udev that now fails to boot your system if CONFIG_DEVTMPFS is > not available in your kernel. > > Bugs: 408947, 409393, 437320, 453074 > > CONFIG_CHECK has not been fatal for some years now, because there turned > out to be some cases where it cannot detect what the system really has > [1], or what is returned is wrong [2]. > > However, while this is has been superb in helping those corner-cases, > the fallout is that users frequently ignore the non-fatal warnings that > a configuration option is needed to run a binary later, and end up with > weird breakage. > > This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to > enabled, that explicitly causes a die if: > - CONFIG_CHECK cannot be performed successfully. > - Any CONFIG_CHECK options fail. [...] Is there any syntax to check if something is either disabled or built as a module? One case where being fatal by default would be annoying and perhaps wrong is net-wireless/broadcom-sta, where there is no problem in having b43 and ssb as modules, as far as they are not loaded when you want to use broadcom's binary driver. (In fact, even if it is not fatal right now, the message ends up being a bit misleading, because it *can* be set.) -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
[gentoo-dev] Lastrite: net-misc/gtk-youtube-viewer
functionality is now provided by >=net-misc/youtube-viewer[gtk]-3.0.3 bug 453580 removal in 30 days
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 25/01/2013 15:23, Dirkjan Ochtman wrote: > Even so, I could downgrade and revdep-rebuild after that, and it > should Just Work, right? Yes and no — you're safer if you get rid of the .so.1 first then revdep-rebuild (if you're using preserved-libs). I know there should be support for ldconfig NOT to re-create the links to the highest library by default for .so files, but I wouldn't bet on it as I've seen other things causing ldconfig to run and overwrite them outside Portage. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Fri, Jan 25, 2013 at 3:17 PM, Ian Stakenvicius wrote: > Depends on whether or not you rebuilt the rdeps -- udev-197 provides > libudev.so.1 while udev-171 provides libudev.so.0 , so there's > breakage on stuffs like lvm2 and other ebuilds that link to libudev Even so, I could downgrade and revdep-rebuild after that, and it should Just Work, right? IIRC, I had nothing rebuilt by revdep-rebuilt after merging udev-197, so maybe this is not an issue for me. Maybe you could add a note about this to the news item? Cheers, Dirkjan
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/01/13 04:19 AM, Dirkjan Ochtman wrote: > On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen > wrote: >>> > Also, after installing udev-197, are there any negative > consequences to just downgrading to -171 again? > Depends on whether or not you rebuilt the rdeps -- udev-197 provides libudev.so.1 while udev-171 provides libudev.so.0 , so there's breakage on stuffs like lvm2 and other ebuilds that link to libudev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlECk+IACgkQ2ugaI38ACPDiPQEArL3Abb2QWi+/uM31+2Nr2wmY GnNGk0ScrqjMA0YuH5gBAI2y8hnzVP/99GwqlwRBnfOav/IftQMSEDzwkKIJhLi4 =EUug -END PGP SIGNATURE-
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Fri, Jan 25, 2013 at 12:59 PM, Rich Freeman wrote: > I could see making that the default if there is no .config file > present and a new one is being created, and perhaps upstream would > support that since udev is popular. However, make oldconfig is > usually used when you have a .config file and you just want to update > it. In that case I don't think we should be changing settings - what > if a user doesn't want this set? They'd have to remember to manually > unset it every single time they compile a new kernel, as we'd be > "helpfully" changing it back. Ah yeah, I mistakenly assumed that DEVTMPFS was a relatively new option. Cheers, Dirkjan
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Fri, Jan 25, 2013 at 4:19 AM, Dirkjan Ochtman wrote: > On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen wrote: >> please review this news item, seems we need one after all > > Here's a crazy idea: can we patch our kernel to let "make oldconfig" > default CONFIG_DEVTMPFS to true? Or better yet, request that this is > changed upstream? I could see making that the default if there is no .config file present and a new one is being created, and perhaps upstream would support that since udev is popular. However, make oldconfig is usually used when you have a .config file and you just want to update it. In that case I don't think we should be changing settings - what if a user doesn't want this set? They'd have to remember to manually unset it every single time they compile a new kernel, as we'd be "helpfully" changing it back. Not everybody uses udev. Somebody already brought this up, but the main thing users need is notice for changes like this, and warnings. By all means mention in the warnings that their systems will be unbootable. And by all means let's cut down on spurious elog traffic otherwise. Oh, here's another thought - when elog traffic gets sent out as email can the subject line be changed based on the most serious message in the log? That is, can a log-only email be distinguished from one that has a warning in it? Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen wrote: > please review this news item, seems we need one after all Here's a crazy idea: can we patch our kernel to let "make oldconfig" default CONFIG_DEVTMPFS to true? Or better yet, request that this is changed upstream? Also, after installing udev-197, are there any negative consequences to just downgrading to -171 again? Cheers, Dirkjan
