* Philipp Kern [111227 04:04]:
> > As you pointed out so nicely: modules_disabled is only a replacement if
> > you have a custom initramfs and do not allow that to be modified
> > automatically. So from the point of the original discussion,
> > modules_disabled is no solution.
>
> You just stuff a
Le mardi 27 décembre 2011 à 08:53 +0100, Josselin Mouette a écrit :
> Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
> > If someone would give even *one* example where something legitimately needed
> > by a udev rule could not be moved from /usr to / without breaking interfaces
Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
> If someone would give even *one* example where something legitimately needed
> by a udev rule could not be moved from /usr to / without breaking interfaces
> or otherwise complicating matters, then that would be worth discussing.
* Andrey Rahmatullin [111227 07:53]:
> On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote:
> > > It is a good thing to run with minimum privs, but compiling a new kernel
> > > to
> > > support this seems to be a lot of work for a fairly small benefit.
> > First of all it is quite a
On Mon, 2011-12-26 at 22:17 +, Philip Hands wrote:
> On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote:
> > On Dec 26, Thomas Goirand wrote:
> >
> > > On 12/22/2011 07:19 PM, Philip Hands wrote:
> > > > I'm still yet to understand the significant upsides of this proposal
On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote:
> > It is a good thing to run with minimum privs, but compiling a new kernel to
> > support this seems to be a lot of work for a fairly small benefit.
> First of all it is quite a significant benefit. And you get quite some
> other a
Adam Borowski writes:
>> And things may change yet again in the future. With Btrfs, one can
>> have a single filesystem with multiple subvolumes. The subvolumes
>> can be mounted independently, and also snapshotted independently,
>> but have a common pool for free data, so unlike partitions any
Hello,
The latest Boost (1.48) is now in testing, and I'd like to switch the
defaults. My first plan was to simply announce the switch then make
it. I did so and got an immediate email from the release team
asking to revert the default change, which I did.
On Tue, Dec 20, 2011 at 08:00:15PM -0
On 2011-12-26, Bernhard R. Link wrote:
> * Philipp Kern [111226 12:02]:
>> Sorry, but what kind of argumentation is that? If the admin doesn't notice
>> reboots and/or file tampering, I could just replace the kernel with my
>> modified
>> one and reboot. Now of course you could increase your p
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote:
> Not quite. Redhat and others want to make this change (moving binaries
> and libraries from / into /usr) not just for ease of maintenance (though
> that makes sense too) but for several rather interesting reasons. It
> would consoli
On Sat, Dec 24, 2011 at 07:03:10PM +0800, Paul Wise wrote:
> > I'd still like to know what the compelling reason for the change is
> > though.
> Apparently the reason is simply that our upstreams (who it sounds like
> are predominantly driven by Redhat folks) are dropping support for /
> and /usr
On 26/12/11 14:15, Russell Coker wrote:
> But it seems to me that a more useful feature would be the ability to create
> a
> white-list of which modules can be loaded to solve the problem of unwanted
> triggers for module loading and the problem of buggy kernel modules being
> autoloaded in res
jida...@jidanni.org writes:
>
> Filesystem 1K-blocksUsed
> Available Use% Mounted on
> rootfs 1071468 287940
> 729100 29% /
> /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071
On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote:
> On Dec 26, Thomas Goirand wrote:
>
> > On 12/22/2011 07:19 PM, Philip Hands wrote:
> > > I'm still yet to understand the significant upsides of this proposal
> > So far, the only upside that has been written here, if I unde
On Dec 26, Thomas Goirand wrote:
> On 12/22/2011 07:19 PM, Philip Hands wrote:
> > I'm still yet to understand the significant upsides of this proposal
> So far, the only upside that has been written here, if I understand
> well, is less patches for upstream udev, which is important since we
> do
On 12/09/2011 03:21 PM, Goswin von Brederlow wrote:
> As I mentioned I have a bug open (in the grml bug tracker) about
> providing a grml.deb. That would install an image in /boot and add
> itself to the bootloader. The small grml image is more like 180MB than
> 25-50MB but it is a verry good rescu
On 12/22/2011 05:50 PM, Marco d'Itri wrote:
> The main objections so far can be summarized as "I like to do thing my
> way and changes make me unconfortable".
>
No, the main objection is:
I have already many systems/servers in production already. Please don't
break them.
I don't mind if using
On 12/22/2011 07:19 PM, Philip Hands wrote:
> I'm still yet to understand the significant upsides of this proposal
So far, the only upside that has been written here, if I understand
well, is less patches for upstream udev, which is important since we
don't have enough people to work on alternative
* Russell Coker [111226 14:16]:
> For many of the things that can be done by loading a kernel module an attacker
> can achieve similar goals by replacing libc or by using ptrace to install
> hostile code in a long-running process that runs as root.
Except replacing libc does not help against stat
* Philipp Kern [111226 12:02]:
> Sorry, but what kind of argumentation is that? If the admin doesn't notice
> reboots and/or file tampering, I could just replace the kernel with my
> modified
> one and reboot. Now of course you could increase your paranoia and boot the
> kernel from an immutabl
On Dec 26, Russell Coker wrote:
> For many of the things that can be done by loading a kernel module an
> attacker
> can achieve similar goals by replacing libc or by using ptrace to install
> hostile code in a long-running process that runs as root.
Or load code in the kernel using /dev/mem,
On Mon, 26 Dec 2011, Iustin Pop wrote:
> > No longer needed. See /proc/sys/kernel/modules_disabled.
>
> That's not equivalent - an attacker that can load modules can also
> remove the init script that sets this variable to 1 and reboot the
> machine.
For many of the things that can be done by l
On Mon, Dec 26, 2011 at 04:42:45PM +0600, Andrey Rahmatullin wrote:
> On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
> > > > All admins I know have at least some servers with custom kernels (in the
> > > > past it was said, to build your firewall/server kernels without module
> > > > s
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
> On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote:
> > On 2011-12-25, Stephan Seitz wrote:
> > > All admins I know have at least some servers with custom kernels (in the
> > > past it was said, to build your firewall/server k
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
> > > All admins I know have at least some servers with custom kernels (in the
> > > past it was said, to build your firewall/server kernels without module
> > > support, so that no rootkit module could be loaded).
> >
> > No longer neede
On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote:
> On 2011-12-25, Stephan Seitz wrote:
> > All admins I know have at least some servers with custom kernels (in the
> > past it was said, to build your firewall/server kernels without module
> > support, so that no rootkit module could b
On Lu, 26 dec 11, 15:37:03, Russell Coker wrote:
> >
> > At least a couple of years ago if you left /home with no free space, kdm
> > (or something under the hood) would be unable to create ~/.Xauthority-*
> > files, making it impossible to log into a graphical session.
Still true with Squeeze.
27 matches
Mail list logo
