Linux 3.6

Linux 3.6

[Linus Torvalds]

When I did the -rc7 announcement a week ago, I said I might have to do
an -rc8, but a week passed, and things have been calm, and I honestly
cannot see a major reason to do another rc.

So here it is, 3.6 final. Sure, I'd have been happier with even fewer
changes, but that just never happens. And holding off the release
until people get too bored to send me the small stuff just makes the
next merge window more painful.

The changes that got merged this week were generally pretty tiny, but
more importantly, they tend to be small or very unlikely/special
things. Famous last words.

The shortlog below is obviously just the log since -rc7, the changes
in 3.6 since 3.5 are too many to list. There haven't been any huge new
architectures or filesystems, it's all "solid progress". That may not
sound all that exciting, but the devil is in the details, and there's
a lot of small fixes all over.

Anyway, this obviously means that the merge window for 3.7 is open,
and on that subject I do want to note that I'm going to travel much of
this merge window. Let's see how much that impacts my merging, but I
hope that it won't be *that* noticeable. But in case it results in any
problems, I'll just give a heads-up, and if worst comes to worst I'll
just extend the merge window to give myself more time for merging. I
aim to avoid it, but I'll note it here just in case it happens.

Steven Rothwell already noted during the -rc7 release that people
should have the stuff for 3.7 in linux-next, and I hope that is true.
Guys and gals, please behave, ok?

                 Linus

---
Al Viro (6):
      do_add_mount()/umount -l races
      close the race in nlmsvc_free_block()
      um: take cleaning singlestep to start_thread()
      um: don't leak floating point state and segment registers on execve()
      um: let signal_delivered() do SIGTRAP on singlestepping into handler
      um: kill thread->forking

Alan Stern (1):
      USB: Fix race condition when removing host controllers

Alex Elder (2):
      rbd: drop dev reference on error in rbd_open()
      libceph: only kunmap kmapped pages

Alex Williamson (3):
      vfio: Trivial Documentation correction
      vfio: Fix virqfd release race
      iommu: static inline iommu group stub functions

Andrea Arcangeli (1):
      thp: avoid VM_BUG_ON page_count(page) false positives in
__collapse_huge_page_copy

Andrei Emeltchenko (1):
      Bluetooth: Fix freeing uninitialized delayed works

Andrew Lunn (1):
      ARM: Orion5x: Fix too small coherent pool.

Andrzej Kaczmarek (2):
      Bluetooth: mgmt: Fix enabling SSP while powered off
      Bluetooth: mgmt: Fix enabling LE while powered off

Ben Skeggs (3):
      drm/nouveau: silence a debug message triggered by newer userspace
      drm/nvc0/ltcg: mask off intr 0x10
      drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN

Chris Metcalf (1):
      tile: gxio iorpc numbering change for TRIO interface

Dan Carpenter (2):
      NVMe: handle allocation failure in nvme_map_user_pages()
      vmwgfx: corruption in vmw_event_fence_action_create()

Daniel Mack (1):
      ALSA: snd-usb: fix next_packet_size calls for pause case

Dave Airlie (1):
      drm/udl: limit modes to the sku pixel limits.

Dave Jiang (1):
      MAINTAINERS: update Intel C600 SAS driver maintainers

Def (1):
      batman-adv: Fix change mac address of soft iface.

Emmanuel Grumbach (1):
      iwlwifi: don't double free the interrupt in failure path

Eric Dumazet (4):
      ipv4: raw: fix icmp_filter()
      net: guard tcp_set_keepalive() to tcp sockets
      ipv6: raw: fix icmpv6_filter()
      ipv6: mip6: fix mip6_mh_filter()

Geert Uytterhoeven (1):
      um: Preinclude include/linux/kern_levels.h

Heiko Carstens (1):
      checksyscalls: fix "here document" handling

J. Bruce Fields (1):
      trivial select_parent documentation fix

Jan Engelhardt (1):
      netfilter: xt_limit: have r->cost != 0 case work

Jan Kara (1):
      lib/flex_proportions.c: fix corruption of denominator in
flexible proportions

Jiri Pirko (1):
      team: send port changed when added

Joachim Eastwood (1):
      USB: ohci-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq

Joerg Roedel (1):
      iommu/amd: Fix wrong assumption in iommu-group specific code

Keith Busch (7):
      NVMe: Set request queue logical block size
      NVMe: Fix nvme module init when nvme_major is set
      NVMe: replace nvme_ns with nvme_dev for user admin
      NVMe: use namespace id for nvme_get_features
      NVMe: Set block queue max sectors
      NVMe: Do not set IO queue depth beyond device max
      NVMe: Fix uninitialized iod compiler warning

Konrad Rzeszutek Wilk (1):
      xen/boot: Disable NUMA for PV guests.

Linus Lüssing (1):
      batman-adv: Fix symmetry check / route flapping in multi interface setups

Linus Torvalds (2):
      mtdchar: fix offset overflow detection
      Linux 3.6

Luis R. Rodriguez (1):
      cfg80211: fix possible circular lock on reg_regdb_search()

Marek Vasut (4):
      phy/micrel: Implement support for KSZ8021
      phy/micrel: Rename KS80xx to KSZ80xx
      phy/micrel: Add missing header to micrel_phy.h
      net: phy: smsc: Implement PHY config_init for LAN87xx

Mark Brown (1):
      ASoC: wm2000: Correct register size

Mark Salter (3):
      c6x: use asm-generic/barrier.h
      c/r: prctl: fix build error for no-MMU case
      syscalls: add __NR_kcmp syscall to generic unistd.h

Matthew Wilcox (3):
      NVMe: Fix whitespace damage in nvme_init
      NVMe: Free admin queue memory on initialisation failure
      NVMe: Cancel outstanding IOs on queue deletion

Mauro Carvalho Chehab (3):
      i3200_edac: Fix memory rank size
      i5000: Fix the memory size calculation with 2R memories
      sb_edac: Avoid overflow errors at memory size calculation

Mike Snitzer (6):
      dm thin: do not set discard_zeroes_data
      dm mpath: only retry ioctl when no paths if queue_if_no_path set
      dm: handle requests beyond end of device instead of using BUG_ON
      dm: retain table limits when swapping to new table with no devices
      dm thin: tidy discard support
      dm thin: fix discard support for data devices

Miklos Szeredi (1):
      vfs: dcache: fix deadlock in tree traversal

Mikulas Patocka (1):
      dm verity: fix overflow check

Milan Broz (1):
      dm table: clear add_random unless all devices have it set

Narendra K (1):
      qlcnic: Fix scheduling while atomic bug

Neil Horman (1):
      bnx2: Clean up remaining iounmap

NeilBrown (2):
      md/raid5: add missing spin_lock_init.
      md/raid10: fix "enough" function for detecting if array is failed.

Nicolas Dichtel (1):
      inetpeer: fix token initialization

Paul Mundt (1):
      sh: pfc: Fix up GPIO mux type reconfig case.

Peter Hüwe (1):
      net/phy/bcm87xx: Add MODULE_LICENSE("GPL") to GPL driver

Quoc-Son Anh (1):
      NVMe: Use ida for nvme device instance

Richard Weinberger (1):
      um: Fix IPC on um

Roland Stigge (1):
      gpio-lpc32xx: Fix value handling of gpio_direction_output()

Sachin Kamat (1):
      ARM: dma-mapping: Fix potential memory leak in atomic_pool_init()

Steve Glendinning (1):
      smsc75xx: fix resume after device reset

Thierry Reding (1):
      pwm-backlight: take over maintenance

Vinicius Costa Gomes (1):
      Bluetooth: Fix not removing power_off delayed work

Wei Yongjun (4):
      l2tp: fix return value check
      team: fix return value check
      netdev: pasemi: fix return value check in pasemi_mac_phy_init()
      netdev: octeon: fix return value check in octeon_mgmt_init_phy()

Xiaodong Xu (1):
      pppoe: drop PPPOX_ZOMBIEs in pppoe_release

Re: Linux 3.6

[Nick Bowler]

On 2012-09-30 17:38 -0700, Linus Torvalds wrote:
> So here it is, 3.6 final. Sure, I'd have been happier with even fewer
> changes, but that just never happens. And holding off the release
> until people get too bored to send me the small stuff just makes the
> next merge window more painful.

Just upgraded to 3.6 from 3.5, and now some of my kernel build scripts
are throwing "permission denied" errors.  Apparently symlinks are
broken somehow?

  # id
  uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

  # ls -l /scratch_space/linux
  drwxr-xr-x 24 nbowler eng 4096 2012-10-03 13:41 /scratch_space/linux

  # readlink /scratch_space/linux-2.6
  linux

  # cd /scratch_space/linux
  # pwd
  /scratch_space/linux

  # cd /scratch_space/linux-2.6
  cd: permission denied: /scratch_space/linux-2.6

WTF?  3.5 is fine.  I will try to bisect this later, but I figured I'd
throw this out there now in case anyone has any ideas...

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Linux 3.6

[Kees Cook]

Hi Nick,

3.6 introduced link restrictions:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7

It sounds like you've got symlinks in a world-writable directory, and
you're following those symlinks across mis-matched uids. You can either
have the symlinks be owned by the directory owner, or you can turn off
symlink restrictions in sysctl:

# echo 0 > /proc/sys/fs/protected_symlinks

-Kees

On Wed, Oct 03, 2012 at 03:46:14PM -0400, Nick Bowler wrote:
> On 2012-09-30 17:38 -0700, Linus Torvalds wrote:
> > So here it is, 3.6 final. Sure, I'd have been happier with even fewer
> > changes, but that just never happens. And holding off the release
> > until people get too bored to send me the small stuff just makes the
> > next merge window more painful.
> 
> Just upgraded to 3.6 from 3.5, and now some of my kernel build scripts
> are throwing "permission denied" errors.  Apparently symlinks are
> broken somehow?
> 
>   # id
>   uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
> 
>   # ls -l /scratch_space/linux
>   drwxr-xr-x 24 nbowler eng 4096 2012-10-03 13:41 /scratch_space/linux
> 
>   # readlink /scratch_space/linux-2.6
>   linux
> 
>   # cd /scratch_space/linux
>   # pwd
>   /scratch_space/linux
> 
>   # cd /scratch_space/linux-2.6
>   cd: permission denied: /scratch_space/linux-2.6
> 
> WTF?  3.5 is fine.  I will try to bisect this later, but I figured I'd
> throw this out there now in case anyone has any ideas...
> 
> Cheers,
> -- 
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Kees Cook                                            @outflux.net

Re: Linux 3.6

[Linus Torvalds]

On Wed, Oct 3, 2012 at 1:05 PM, Kees Cook <kees@outflux.net> wrote:
>
> 3.6 introduced link restrictions:

Hmm. If this causes problems for others, I suspect we need to turn it
off by default.

It's a nice security thing, but considering how quickly people started
complaining after 3.6 was out, I suspect we'll see more of these, and
we may not have any choice.

             Linus

Re: Linux 3.6

[Theodore Ts'o]

On Wed, Oct 03, 2012 at 01:29:15PM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:05 PM, Kees Cook <kees@outflux.net> wrote:
> >
> > 3.6 introduced link restrictions:
> 
> Hmm. If this causes problems for others, I suspect we need to turn it
> off by default.
> 
> It's a nice security thing, but considering how quickly people started
> complaining after 3.6 was out, I suspect we'll see more of these, and
> we may not have any choice.

True, although I'm not sure we should be encouraging kernel developers
to have world-writeable directories.  I suppose if it's a single-user
workstation it wouldn't matter, but you could imagine a daemon running
has "nobody" which has a stack overflow bug, and then if the user has
been careless and uses umasks so that directories in their home
directory are world writeable, well.....

Regardless of whether or not we turn this security feature off by
default, I think it's worthwhile to look at how and why did Nick's
directories become world-writeable, and whether there is so distro
default which is causing or encouraging this.

					 - Ted

Re: Linux 3.6

[Kees Cook]

On Wed, Oct 03, 2012 at 04:41:41PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 03, 2012 at 01:29:15PM -0700, Linus Torvalds wrote:
> > On Wed, Oct 3, 2012 at 1:05 PM, Kees Cook <kees@outflux.net> wrote:
> > >
> > > 3.6 introduced link restrictions:
> > 
> > Hmm. If this causes problems for others, I suspect we need to turn it
> > off by default.
> > 
> > It's a nice security thing, but considering how quickly people started
> > complaining after 3.6 was out, I suspect we'll see more of these, and
> > we may not have any choice.
> 
> True, although I'm not sure we should be encouraging kernel developers
> to have world-writeable directories.  I suppose if it's a single-user
> workstation it wouldn't matter, but you could imagine a daemon running
> has "nobody" which has a stack overflow bug, and then if the user has
> been careless and uses umasks so that directories in their home
> directory are world writeable, well.....
> 
> Regardless of whether or not we turn this security feature off by
> default, I think it's worthwhile to look at how and why did Nick's
> directories become world-writeable, and whether there is so distro
> default which is causing or encouraging this.

I think the benefits of this being on by default outweigh glitches
like this. Based on Nick's email, it looks like a directory tree of his
own creation.

-Kees

-- 
Kees Cook                                            @outflux.net

Re: Linux 3.6

[Alan Cox]

On Wed, 3 Oct 2012 13:05:15 -0700
Kees Cook <kees@outflux.net> wrote:

> Hi Nick,
> 
> 3.6 introduced link restrictions:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7
> 
> It sounds like you've got symlinks in a world-writable directory, and
> you're following those symlinks across mis-matched uids. You can either
> have the symlinks be owned by the directory owner, or you can turn off
> symlink restrictions in sysctl:
> 
> # echo 0 > /proc/sys/fs/protected_symlinks

Quite honestly that should be pushed for 3.6.1 as a default - ASAP.

Alan

Re: Linux 3.6

[Linus Torvalds]

On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@outflux.net> wrote:
>
> I think the benefits of this being on by default outweigh glitches
> like this. Based on Nick's email, it looks like a directory tree of his
> own creation.

I agree that *one* report like this doesn't necessarily mean that we
need to turn it off, if Nick is happy to just fix up his script and
it's all local.

However, I suspect we'll see more. And once that happens, we're not
going to keep a default that breaks peoples old scripts, and we're
going to have to rely on distributions (or users) explicitly setting
it.

Compatibility is just too important.

            Linus

Re: Linux 3.6

[Kees Cook]

On Wed, Oct 03, 2012 at 01:54:21PM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@outflux.net> wrote:
> >
> > I think the benefits of this being on by default outweigh glitches
> > like this. Based on Nick's email, it looks like a directory tree of his
> > own creation.
> 
> I agree that *one* report like this doesn't necessarily mean that we
> need to turn it off, if Nick is happy to just fix up his script and
> it's all local.
> 
> However, I suspect we'll see more. And once that happens, we're not
> going to keep a default that breaks peoples old scripts, and we're
> going to have to rely on distributions (or users) explicitly setting
> it.
> 
> Compatibility is just too important.

If this happens, I _really_ want to bring back the CONFIG options I had in
an earlier version of this patch. I want to be able to declare the default
at build time, and not leave a system vulnerable from boot until sysctls
get set.

-Kees

-- 
Kees Cook                                            @outflux.net

Re: Linux 3.6

[Kees Cook]

On Wed, Oct 03, 2012 at 10:05:25PM +0100, Alan Cox wrote:
> > If this happens, I _really_ want to bring back the CONFIG options I had in
> > an earlier version of this patch. I want to be able to declare the default
> > at build time, and not leave a system vulnerable from boot until sysctls
> > get set.
> 
> If your early boot code trusts a random writeable user directory I think
> you have other problems.

You should see some of the things various Android devices do! :)

-Kees

-- 
Kees Cook                                            @outflux.net

Re: Linux 3.6

[Alan Cox]

> If this happens, I _really_ want to bring back the CONFIG options I had in
> an earlier version of this patch. I want to be able to declare the default
> at build time, and not leave a system vulnerable from boot until sysctls
> get set.

If your early boot code trusts a random writeable user directory I think
you have other problems.

Re: Linux 3.6

[Matthias Schniedermeyer]

On 03.10.2012 13:05, Kees Cook wrote:
> Hi Nick,
> 
> 3.6 introduced link restrictions:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7
> 
> It sounds like you've got symlinks in a world-writable directory, and
> you're following those symlinks across mis-matched uids. You can either
> have the symlinks be owned by the directory owner, or you can turn off
> symlink restrictions in sysctl:
> 
> # echo 0 > /proc/sys/fs/protected_symlinks

According to documentation world writable isn't the problem.
It's world writable inside/or below a directory with sticky bit.
(Documentation/sysctl/fs.txt -> protected_symlinks)

So /scratch_space must have the sticky bit set.
Question is: Why?


Personally i would have been bitten by this change, because for years i 
have used a symlink in /tmp (which has the sticky bit) to a directory 
somewhere else for historical reasons. But as i was aware of this change 
i fixed my system before booting the new kernel.


> On Wed, Oct 03, 2012 at 03:46:14PM -0400, Nick Bowler wrote:
> > On 2012-09-30 17:38 -0700, Linus Torvalds wrote:
> > > So here it is, 3.6 final. Sure, I'd have been happier with even fewer
> > > changes, but that just never happens. And holding off the release
> > > until people get too bored to send me the small stuff just makes the
> > > next merge window more painful.
> > 
> > Just upgraded to 3.6 from 3.5, and now some of my kernel build scripts
> > are throwing "permission denied" errors.  Apparently symlinks are
> > broken somehow?
> > 
> >   # id
> >   uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
> > 
> >   # ls -l /scratch_space/linux
> >   drwxr-xr-x 24 nbowler eng 4096 2012-10-03 13:41 /scratch_space/linux
> > 
> >   # readlink /scratch_space/linux-2.6
> >   linux
> > 
> >   # cd /scratch_space/linux
> >   # pwd
> >   /scratch_space/linux
> > 
> >   # cd /scratch_space/linux-2.6
> >   cd: permission denied: /scratch_space/linux-2.6
> > 
> > WTF?  3.5 is fine.  I will try to bisect this later, but I figured I'd
> > throw this out there now in case anyone has any ideas...






Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

Re: Linux 3.6

[Theodore Ts'o]

On Thu, Oct 04, 2012 at 12:23:41AM +0200, Matthias Schniedermeyer wrote:
> Personally i would have been bitten by this change, because for years i 
> have used a symlink in /tmp (which has the sticky bit) to a directory 
> somewhere else for historical reasons. But as i was aware of this change 
> i fixed my system before booting the new kernel.

As long as you own the symlink, it wouldn't be a problem.  The problem
comes when the symlink is owned by some user such as
"untrusted_daemon", which could change where the symlink could point
at any any time --- or could create a new symlink where none had
previously existed in some world-writeable directory such as /tmp.

Now you try to use that symlink, assuming that it points to *foo*,
when in fact it now points to *bar*, and hilarity ensues...

						- Ted

Re: Linux 3.6

[Nick Bowler]

On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@outflux.net> wrote:
> > I think the benefits of this being on by default outweigh glitches
> > like this. Based on Nick's email, it looks like a directory tree of his
> > own creation.
> 
> I agree that *one* report like this doesn't necessarily mean that we
> need to turn it off, if Nick is happy to just fix up his script and
> it's all local.
> 
> However, I suspect we'll see more. And once that happens, we're not
> going to keep a default that breaks peoples old scripts, and we're
> going to have to rely on distributions (or users) explicitly setting
> it.

Yes, it is a directory of my own creation, intended as a place for users
(read: me) to stick stuff on the local disk as opposed to on NFS.  It's
pretty trivial for me to fixup everything to not need this symlink
anymore (and I suspect it is the only offender); I just created the
symlink in the first place so that I wouldn't have to change anything
else.

(While on /this/ machine I created the directory, I have used shared lab
machines with a similar setup).

The thing that bothers me most about all this is that it's basically
impossible to see why things are failing without digging through the git
tree or posting to the mailing list (or recalling earlier mailing list
discussions about the restriction, as I vaguely do now).  You just
suddenly get "permission denied" errors when all the permissions
involved look fine.  As far as I know, the owner, group and mode of
symlinks have always been completely meaningless.  Upgrade to 3.6, and
they're suddenly meaningful in extremely non-obvious ways.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Linux 3.6

[Kees Cook]

On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
> On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> > On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@outflux.net> wrote:
> > > I think the benefits of this being on by default outweigh glitches
> > > like this. Based on Nick's email, it looks like a directory tree of his
> > > own creation.
> > 
> > I agree that *one* report like this doesn't necessarily mean that we
> > need to turn it off, if Nick is happy to just fix up his script and
> > it's all local.
> > 
> > However, I suspect we'll see more. And once that happens, we're not
> > going to keep a default that breaks peoples old scripts, and we're
> > going to have to rely on distributions (or users) explicitly setting
> > it.
> 
> Yes, it is a directory of my own creation, intended as a place for users
> (read: me) to stick stuff on the local disk as opposed to on NFS.  It's
> pretty trivial for me to fixup everything to not need this symlink
> anymore (and I suspect it is the only offender); I just created the
> symlink in the first place so that I wouldn't have to change anything
> else.
> 
> (While on /this/ machine I created the directory, I have used shared lab
> machines with a similar setup).
> 
> The thing that bothers me most about all this is that it's basically
> impossible to see why things are failing without digging through the git
> tree or posting to the mailing list (or recalling earlier mailing list
> discussions about the restriction, as I vaguely do now).  You just
> suddenly get "permission denied" errors when all the permissions
> involved look fine.  As far as I know, the owner, group and mode of
> symlinks have always been completely meaningless.  Upgrade to 3.6, and
> they're suddenly meaningful in extremely non-obvious ways.

FWIW, there should have been an audit message about it in dmesg.

-Kees

-- 
Kees Cook                                            @outflux.net

Re: Linux 3.6

[Nick Bowler]

On 2012-10-04 08:49 -0700, Kees Cook wrote:
> On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
> > On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> > > On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@outflux.net> wrote:
> > > > I think the benefits of this being on by default outweigh glitches
> > > > like this. Based on Nick's email, it looks like a directory tree of his
> > > > own creation.
> > > 
> > > I agree that *one* report like this doesn't necessarily mean that we
> > > need to turn it off, if Nick is happy to just fix up his script and
> > > it's all local.
> > > 
> > > However, I suspect we'll see more. And once that happens, we're not
> > > going to keep a default that breaks peoples old scripts, and we're
> > > going to have to rely on distributions (or users) explicitly setting
> > > it.
> > 
> > Yes, it is a directory of my own creation, intended as a place for users
> > (read: me) to stick stuff on the local disk as opposed to on NFS.  It's
> > pretty trivial for me to fixup everything to not need this symlink
> > anymore (and I suspect it is the only offender); I just created the
> > symlink in the first place so that I wouldn't have to change anything
> > else.
> > 
> > (While on /this/ machine I created the directory, I have used shared lab
> > machines with a similar setup).
> > 
> > The thing that bothers me most about all this is that it's basically
> > impossible to see why things are failing without digging through the git
> > tree or posting to the mailing list (or recalling earlier mailing list
> > discussions about the restriction, as I vaguely do now).  You just
> > suddenly get "permission denied" errors when all the permissions
> > involved look fine.  As far as I know, the owner, group and mode of
> > symlinks have always been completely meaningless.  Upgrade to 3.6, and
> > they're suddenly meaningful in extremely non-obvious ways.
> 
> FWIW, there should have been an audit message about it in dmesg.

There were zero messages in the kernel log.

  # dmesg -C
  # cd /tmp
  # mkdir testdir
  # ln -s testdir testlink
  # chown -h nobody testlink
  # cd testlink
  cd: permission denied: testlink
  # dmesg
  (no output)

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Linux 3.6

[Kees Cook]

On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
> > > On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> > > > On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@outflux.net> wrote:
> > > > > I think the benefits of this being on by default outweigh glitches
> > > > > like this. Based on Nick's email, it looks like a directory tree of his
> > > > > own creation.
> > > > 
> > > > I agree that *one* report like this doesn't necessarily mean that we
> > > > need to turn it off, if Nick is happy to just fix up his script and
> > > > it's all local.
> > > > 
> > > > However, I suspect we'll see more. And once that happens, we're not
> > > > going to keep a default that breaks peoples old scripts, and we're
> > > > going to have to rely on distributions (or users) explicitly setting
> > > > it.
> > > 
> > > Yes, it is a directory of my own creation, intended as a place for users
> > > (read: me) to stick stuff on the local disk as opposed to on NFS.  It's
> > > pretty trivial for me to fixup everything to not need this symlink
> > > anymore (and I suspect it is the only offender); I just created the
> > > symlink in the first place so that I wouldn't have to change anything
> > > else.
> > > 
> > > (While on /this/ machine I created the directory, I have used shared lab
> > > machines with a similar setup).
> > > 
> > > The thing that bothers me most about all this is that it's basically
> > > impossible to see why things are failing without digging through the git
> > > tree or posting to the mailing list (or recalling earlier mailing list
> > > discussions about the restriction, as I vaguely do now).  You just
> > > suddenly get "permission denied" errors when all the permissions
> > > involved look fine.  As far as I know, the owner, group and mode of
> > > symlinks have always been completely meaningless.  Upgrade to 3.6, and
> > > they're suddenly meaningful in extremely non-obvious ways.
> > 
> > FWIW, there should have been an audit message about it in dmesg.
> 
> There were zero messages in the kernel log.
> 
>   # dmesg -C
>   # cd /tmp
>   # mkdir testdir
>   # ln -s testdir testlink
>   # chown -h nobody testlink
>   # cd testlink
>   cd: permission denied: testlink
>   # dmesg
>   (no output)

Well that's sad. :( Two situations I can think of for that:
- the kernel wasn't build with CONFIG_AUDIT
- auditd is running and hiding the notices in some other log file

-Kees

-- 
Kees Cook                                            @outflux.net

Re: Linux 3.6

[Nick Bowler]

On 2012-10-04 09:14 -0700, Kees Cook wrote:
> On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> > On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > > On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
[...]
> > > > The thing that bothers me most about all this is that it's basically
> > > > impossible to see why things are failing without digging through the git
> > > > tree or posting to the mailing list (or recalling earlier mailing list
> > > > discussions about the restriction, as I vaguely do now).  You just
> > > > suddenly get "permission denied" errors when all the permissions
> > > > involved look fine.  As far as I know, the owner, group and mode of
> > > > symlinks have always been completely meaningless.  Upgrade to 3.6, and
> > > > they're suddenly meaningful in extremely non-obvious ways.
> > > 
> > > FWIW, there should have been an audit message about it in dmesg.
> > 
> > There were zero messages in the kernel log.
> > 
> >   # dmesg -C
> >   # cd /tmp
> >   # mkdir testdir
> >   # ln -s testdir testlink
> >   # chown -h nobody testlink
> >   # cd testlink
> >   cd: permission denied: testlink
> >   # dmesg
> >   (no output)
> 
> Well that's sad. :( Two situations I can think of for that:
> - the kernel wasn't build with CONFIG_AUDIT

Indeed, I do not have this option enabled.  Why would I have it?  The
description says it's for SELinux, which I do not use.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Linux 3.6

[Stefan Richter]

On Oct 04 Nick Bowler wrote:
> On 2012-10-04 09:14 -0700, Kees Cook wrote:
> > On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> > > On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > > > FWIW, there should have been an audit message about it in dmesg.
> > > 
> > > There were zero messages in the kernel log.
> > > 
> > >   # dmesg -C
> > >   # cd /tmp
> > >   # mkdir testdir
> > >   # ln -s testdir testlink
> > >   # chown -h nobody testlink
> > >   # cd testlink
> > >   cd: permission denied: testlink
> > >   # dmesg
> > >   (no output)
> > 
> > Well that's sad. :( Two situations I can think of for that:
> > - the kernel wasn't build with CONFIG_AUDIT
> 
> Indeed, I do not have this option enabled.  Why would I have it?  The
> description says it's for SELinux, which I do not use.

It says it is /among else/ for SELinux.  Another user appears to be
ConsoleKit, which wants CONFIG_AUDITSYSCALL, which depends on CONFIG_AUDIT.
-- 
Stefan Richter
-=====-===-- =-=- --=--
http://arcgraph.de/sr/

Re: Linux 3.6

[Nick Bowler]

On 2012-10-04 23:30 +0200, Stefan Richter wrote:
> On Oct 04 Nick Bowler wrote:
> > On 2012-10-04 09:14 -0700, Kees Cook wrote:
> > > On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> > > > On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > > > > FWIW, there should have been an audit message about it in dmesg.
[...]
> > > >   # dmesg
> > > >   (no output)
> > > 
> > > Well that's sad. :( Two situations I can think of for that:
> > > - the kernel wasn't build with CONFIG_AUDIT
> > 
> > Indeed, I do not have this option enabled.  Why would I have it?  The
> > description says it's for SELinux, which I do not use.
> 
> It says it is /among else/ for SELinux.  Another user appears to be
> ConsoleKit, which wants CONFIG_AUDITSYSCALL, which depends on CONFIG_AUDIT.

Indeed, you are correct that the help text does imply that there are
(potentially) other users besides SElinux, although it does not say what
they are.  Regardless, the point is that I have no idea why I would have
this optional feature enabled, as I still don't even know what it does
because the help text doesn't actually say.  I even found a website,
http://people.redhat.com/sgrubb/audit/, which seems to be related to
this feature but even here I cannot find one sentence explaining what
the feature is.

Well, from this thread I now know that this feature enables, at least
in some cases, printk messages when your previously-working scripts are
broken by a kernel update.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)