* mount.nfs: access denied by server
@ 2009-08-20 7:13 Wu Fengguang
2009-08-20 7:19 ` Wu Fengguang
2009-08-20 13:02 ` Trond Myklebust
0 siblings, 2 replies; 55+ messages in thread
From: Wu Fengguang @ 2009-08-20 7:13 UTC (permalink / raw)
To: linux-nfs; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
Hi,
After upgrading NFS client kernel to latest linux-next, NFS mount
failed:
# mount -t nfs pxe:/cc /cc
mount.nfs: access denied by server while mounting pxe:/cc
# uname -a
Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20 14:46:10 CST 2009 x86_64 GNU/Linux
However server log says OK:
Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount request from 192.168.11.6:973 for /cc (/cc)
Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount request from 192.168.11.6:974 for /cc (/cc)
However-2: nfsroot can be mounted at boot time. Server kernel has always been 2.6.30.
Any ideas?
Thanks,
Fengguang
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 56911 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.31-rc6
# Thu Aug 20 14:06:35 2009
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_TRACE=y
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_TREE_RCU_TRACE=y
# CONFIG_PREEMPT_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_COUNTERS=y
#
# Performance Counters
#
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB_ALLOCATOR is not set
# CONFIG_SLUB_ALLOCATOR is not set
CONFIG_SLQB_ALLOCATOR=y
CONFIG_SLQB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=y
# CONFIG_OPROFILE_IBS is not set
# CONFIG_OPROFILE_EVENT_MULTIPLEX is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_SLOW_WORK is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLOCK_COMPAT=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_FREEZER=y
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_SPARSE_IRQ=y
CONFIG_NUMA_IRQ_DESC=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
# CONFIG_XEN is not set
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_MEMTEST=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_P6_NOP=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PROCESSOR_SELECT=y
CONFIG_CPU_SUP_INTEL=y
# CONFIG_CPU_SUP_AMD is not set
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_NEW_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_X86_CPU_DEBUG is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
# CONFIG_DIRECT_GBPAGES is not set
CONFIG_NUMA=y
# CONFIG_K8_NUMA is not set
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=6
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
#
# Memory hotplug is currently incompatible with Software Suspend
#
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_MIGRATION is not set
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_MMU_NOTIFIER=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_MEMORY_FAILURE=y
CONFIG_HWPOISON_INJECT=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW_64K=y
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
# CONFIG_X86_PAT is not set
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_VERBOSE is not set
CONFIG_CAN_PM_TRACE=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
CONFIG_ACPI_CUSTOM_DSDT_FILE=""
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=y
# CONFIG_SFI is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_POWERNOW_K8 is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
# CONFIG_X86_P4_CLOCKMOD is not set
#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
# CONFIG_INTR_REMAP is not set
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=y
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_DEFAULT_PS_VALUE=1
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_WIRELESS_OLD_REGULATORY is not set
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=y
#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
CONFIG_MAC80211_DEBUGFS=y
CONFIG_MAC80211_DEBUG_MENU=y
CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT=y
CONFIG_MAC80211_NOINLINE=y
CONFIG_MAC80211_VERBOSE_DEBUG=y
CONFIG_MAC80211_HT_DEBUG=y
CONFIG_MAC80211_TKIP_DEBUG=y
CONFIG_MAC80211_IBSS_DEBUG=y
CONFIG_MAC80211_VERBOSE_PS_DEBUG=y
CONFIG_MAC80211_DEBUG_COUNTERS=y
# CONFIG_MAC80211_DRIVER_API_TRACER is not set
CONFIG_WIMAX=m
CONFIG_WIMAX_DEBUG_LEVEL=8
CONFIG_RFKILL=y
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=65536
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=128
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_VIRTIO_BLK=y
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
CONFIG_HWLAT_DETECTOR=m
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
CONFIG_SCSI_ISCSI_ATTRS=y
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
CONFIG_PATA_PLATFORM=y
# CONFIG_PATA_SCH is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# You can enable one or both FireWire driver stacks.
#
#
# See the help texts for more information.
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
CONFIG_QSEMI_PHY=y
CONFIG_LXT_PHY=y
CONFIG_CICADA_PHY=y
CONFIG_VITESSE_PHY=y
CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_MII=y
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
CONFIG_ATL1=y
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH_COMMON is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
CONFIG_IWLWIFI=m
# CONFIG_IWLWIFI_LEDS is not set
# CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set
# CONFIG_IWLWIFI_DEBUG is not set
CONFIG_IWLAGN=m
CONFIG_IWL4965=y
# CONFIG_IWL5000 is not set
# CONFIG_IWL3945 is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
# CONFIG_HERMES is not set
# CONFIG_WL12XX is not set
#
# WiMAX Wireless Broadband devices
#
#
# Enable MMC support to see WiMAX SDIO drivers
#
# CONFIG_WIMAX_I2400M_USB is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=y
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_VIRTIO_NET=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_NEWTON=y
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_XTKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=y
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_NOZOMI=y
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=y
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_HW_RANDOM_VIA=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=y
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_UMMUNOTIFY=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=m
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set
#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATK0110 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13783 is not set
# CONFIG_AB3100_CORE is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_VGA_ARB=y
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=m
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
CONFIG_FB_INTEL=m
CONFIG_FB_INTEL_DEBUG=y
CONFIG_FB_INTEL_I2C=y
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_PLATFORM is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m
#
# Display hardware drivers
#
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=1024
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
CONFIG_SOUND=m
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_JACK=y
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_SEQUENCER_OSS is not set
CONFIG_SND_HRTIMER=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_SND_PCM_XRUN_DEBUG=y
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_JACK=y
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_USB is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y
#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
# CONFIG_USB_STORAGE is not set
CONFIG_USB_LIBUSUAL=y
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set
#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set
#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
#
# SPI RTC drivers
#
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y
#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=y
CONFIG_DMA_ENGINE=y
#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
CONFIG_DCA=y
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
#
# TI VLYNQ
#
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_SAMSUNG_BACKLIGHT is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set
#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=y
# CONFIG_EXT4DEV_COMPAT is not set
CONFIG_EXT4_FS_XATTR=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_BTRFS_FS=y
# CONFIG_BTRFS_FS_POSIX_ACL is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
# CONFIG_NFS_V4 is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
CONFIG_NLS_CODEPAGE_936=y
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_OBJECTS=y
# CONFIG_DEBUG_OBJECTS_SELFTEST is not set
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_SLQB_DEBUG=y
# CONFIG_SLQB_DEBUG_ON is not set
CONFIG_SLQB_SYSFS=y
CONFIG_SLQB_STATS=y
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
CONFIG_FAULT_INJECTION=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y
# CONFIG_FAIL_IO_TIMEOUT is not set
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FTRACE_NMI_ENTER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_FTRACE_SYSCALLS=y
CONFIG_RING_BUFFER=y
CONFIG_FTRACE_NMI_ENTER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
CONFIG_FTRACE_SYSCALLS=y
CONFIG_BOOT_TRACER=y
# CONFIG_SKB_SOURCES_TRACER is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_POWER_TRACER=y
# CONFIG_STACK_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DEBUG_NX_TEST is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_IMA is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-20 7:13 mount.nfs: access denied by server Wu Fengguang
@ 2009-08-20 7:19 ` Wu Fengguang
2009-08-20 13:02 ` Trond Myklebust
1 sibling, 0 replies; 55+ messages in thread
From: Wu Fengguang @ 2009-08-20 7:19 UTC (permalink / raw)
To: linux-nfs; +Cc: LKML
On Thu, Aug 20, 2009 at 03:13:15PM +0800, Wu Fengguang wrote:
> Hi,
>
> After upgrading NFS client kernel to latest linux-next, NFS mount
> failed:
>
> # mount -t nfs pxe:/cc /cc
> mount.nfs: access denied by server while mounting pxe:/cc
>
> # uname -a
> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20 14:46:10 CST 2009 x86_64 GNU/Linux
>
> However server log says OK:
>
> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount request from 192.168.11.6:973 for /cc (/cc)
> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount request from 192.168.11.6:974 for /cc (/cc)
>
> However-2: nfsroot can be mounted at boot time. Server kernel has always been 2.6.30.
Another bug:
[ 29.096228] general protection fault: 0000 [#1] SMP
[ 29.099602] last sysfs file: /sys/devices/virtual/net/sit0/flags
[ 29.099602] CPU 1
[ 29.099602] Modules linked in: drm iwlagn iwlcore snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc
[ 29.099602] Pid: 3104, comm: mount.nfs Not tainted 2.6.31-rc6-next-20090818 #61
[ 29.099602] RIP: 0010:[<ffffffff812d5aa6>] [<ffffffff812d5aa6>] __list_add+0x26/0xa0
[ 29.099602] RSP: 0018:ffff88001a827d18 EFLAGS: 00010246
[ 29.099602] RAX: ff880018fb288048 RBX: ffff880018fb2880 RCX: ffffffff81e0a6a0
[ 29.099602] RDX: ffff880018fb2880 RSI: ff880018fb288048 RDI: ffff8800189df548
[ 29.099602] RBP: ffff88001a827d38 R08: ffff880018fb29b8 R09: 0000000000000000
[ 29.099602] R10: 0000000000000000 R11: 0000000000000000 R12: ff880018fb288048
[ 29.099602] R13: ffff8800189df548 R14: ffff880018fb28f0 R15: ffff880018fb28f0
[ 29.099602] FS: 0000000000000000(0000) GS:ffff880003a00000(0000) knlGS:0000000000000000
[ 29.099602] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 29.099602] CR2: 00007fd2a085ab40 CR3: 0000000001001000 CR4: 00000000000006e0
[ 29.099602] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 29.099602] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 29.099602] Process mount.nfs (pid: 3104, threadinfo ffff88001a826000, task ffff88001b568f00)
[ 29.099602] Stack:
[ 29.099602] ffffffff81204ce8 ffff880018fb29a0 ffff880018fb28f0 ffff8800189df500
[ 29.099602] <0> ffff88001a827d68 ffffffff81204d0a 0000000300000000 ffff88001888e200
[ 29.099602] <0> ffff880018fb28f0 ffff880018fa1000 ffff88001a827d88 ffffffff81202a51
[ 29.099602] Call Trace:
[ 29.099602] [<ffffffff81204ce8>] ? nfs_release+0x48/0x90
[ 29.099602] [<ffffffff81204d0a>] nfs_release+0x6a/0x90
[ 29.099602] [<ffffffff81202a51>] nfs_file_release+0x61/0x90
[ 29.099602] [<ffffffff8112ca1e>] __fput+0x11e/0x280
[ 29.099602] [<ffffffff8112cba5>] fput+0x25/0x30
[ 29.099602] [<ffffffff81183df8>] removed_exe_file_vma+0x38/0x50
[ 29.099602] [<ffffffff81104d10>] remove_vma+0x90/0xa0
[ 29.099602] [<ffffffff81104e18>] exit_mmap+0xf8/0x180
[ 29.099602] [<ffffffff8104d887>] mmput+0x67/0xd0
[ 29.099602] [<ffffffff81052ead>] exit_mm+0x11d/0x160
[ 29.099602] [<ffffffff81054c08>] do_exit+0x138/0x840
[ 29.099602] [<ffffffff8100c06a>] ? sysret_check+0x2e/0x69
[ 29.099602] [<ffffffff8105535c>] do_group_exit+0x4c/0xc0
[ 29.099602] [<ffffffff810553e7>] sys_exit_group+0x17/0x20
[ 29.099602] [<ffffffff8100c032>] system_call_fastpath+0x16/0x1b
[ 29.099602] Code: 00 00 00 00 00 55 48 89 e5 48 83 ec 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 49 89 f4 48 8b 42 08 49 89 fd 48 89 d3 48 39 f0 75 27 <49> 8b 04 24 48 39 d8 75 43 4c 89 6b 08 49 89 5d 00 4d 89 65 08
[ 29.359600] RIP [<ffffffff812d5aa6>] __list_add+0x26/0xa0
[ 29.359600] RSP <ffff88001a827d18>
[ 29.369139] ---[ end trace 8c118d638a30b42e ]---
[ 29.373847] Fixing recursive fault but reboot is needed!
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-20 7:13 mount.nfs: access denied by server Wu Fengguang
2009-08-20 7:19 ` Wu Fengguang
@ 2009-08-20 13:02 ` Trond Myklebust
2009-08-21 1:27 ` Wu Fengguang
1 sibling, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-20 13:02 UTC (permalink / raw)
To: Wu Fengguang; +Cc: linux-nfs, LKML
On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
> Hi,
>
> After upgrading NFS client kernel to latest linux-next, NFS mount
> failed:
>
> # mount -t nfs pxe:/cc /cc
> mount.nfs: access denied by server while mounting pxe:/cc
>
> # uname -a
> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20 14:46:10 CST 2009 x86_64 GNU/Linux
>
> However server log says OK:
>
> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount request from 192.168.11.6:973 for /cc (/cc)
> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount request from 192.168.11.6:974 for /cc (/cc)
>
> However-2: nfsroot can be mounted at boot time. Server kernel has always been 2.6.30.
>
> Any ideas?
>
> Thanks,
> Fengguang
Can you try again after enabling mount debugging on the NFS client?
echo 512 > /proc/sys/sunrpc/nfs_debug
Cheers
Trond
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
@ 2009-08-21 1:27 ` Wu Fengguang
0 siblings, 0 replies; 55+ messages in thread
From: Wu Fengguang @ 2009-08-21 1:27 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, LKML
On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
> > Hi,
> >
> > After upgrading NFS client kernel to latest linux-next, NFS mount
> > failed:
> >
> > # mount -t nfs pxe:/cc /cc
> > mount.nfs: access denied by server while mounting pxe:/cc
> >
> > # uname -a
> > Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20 14:46:10 CST 2009 x86_64 GNU/Linux
> >
> > However server log says OK:
> >
> > Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount request from 192.168.11.6:973 for /cc (/cc)
> > Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount request from 192.168.11.6:974 for /cc (/cc)
> >
> > However-2: nfsroot can be mounted at boot time. Server kernel has always been 2.6.30.
> >
> > Any ideas?
> >
> > Thanks,
> > Fengguang
>
> Can you try again after enabling mount debugging on the NFS client?
>
> echo 512 > /proc/sys/sunrpc/nfs_debug
I used 1024 and found the mount failed here in nfs_walk_authlist():
dfprintk(MOUNT, "NFS: server does not support requested auth flavor\ n");
nfs_umount(request);
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
@ 2009-08-21 1:27 ` Wu Fengguang
0 siblings, 0 replies; 55+ messages in thread
From: Wu Fengguang @ 2009-08-21 1:27 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, LKML
On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
> > Hi,
> >
> > After upgrading NFS client kernel to latest linux-next, NFS mount
> > failed:
> >
> > # mount -t nfs pxe:/cc /cc
> > mount.nfs: access denied by server while mounting pxe:/cc
> >
> > # uname -a
> > Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20 14:46:10 CST 2009 x86_64 GNU/Linux
> >
> > However server log says OK:
> >
> > Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount request from 192.168.11.6:973 for /cc (/cc)
> > Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount request from 192.168.11.6:974 for /cc (/cc)
> >
> > However-2: nfsroot can be mounted at boot time. Server kernel has always been 2.6.30.
> >
> > Any ideas?
> >
> > Thanks,
> > Fengguang
>
> Can you try again after enabling mount debugging on the NFS client?
>
> echo 512 > /proc/sys/sunrpc/nfs_debug
I used 1024 and found the mount failed here in nfs_walk_authlist():
dfprintk(MOUNT, "NFS: server does not support requested auth flavor\ n");
nfs_umount(request);
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 1:27 ` Wu Fengguang
(?)
@ 2009-08-21 2:36 ` Trond Myklebust
2009-08-21 17:50 ` Chuck Lever
2009-08-21 18:16 ` Fwd: " Chuck Lever
-1 siblings, 2 replies; 55+ messages in thread
From: Trond Myklebust @ 2009-08-21 2:36 UTC (permalink / raw)
To: Wu Fengguang, Mr. Charles Edward Lever; +Cc: linux-nfs, LKML
On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
> > On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
> > > Hi,
> > >
> > > After upgrading NFS client kernel to latest linux-next, NFS mount
> > > failed:
> > >
> > > # mount -t nfs pxe:/cc /cc
> > > mount.nfs: access denied by server while mounting pxe:/cc
> > >
> > > # uname -a
> > > Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20 14:46:10 CST 2009 x86_64 GNU/Linux
> > >
> > > However server log says OK:
> > >
> > > Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount request from 192.168.11.6:973 for /cc (/cc)
> > > Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount request from 192.168.11.6:974 for /cc (/cc)
> > >
> > > However-2: nfsroot can be mounted at boot time. Server kernel has always been 2.6.30.
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > > Fengguang
> >
> > Can you try again after enabling mount debugging on the NFS client?
> >
> > echo 512 > /proc/sys/sunrpc/nfs_debug
>
> I used 1024 and found the mount failed here in nfs_walk_authlist():
>
> dfprintk(MOUNT, "NFS: server does not support requested auth flavor\ n");
> nfs_umount(request);
Thanks Fengguang!
Chuck, this looks like one of yours. Could it be that you are hitting
the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
AFAICR, the problem was that existing nfs servers do not set a default
auth flavour, and so you just have to try with auth_sys and see if it
succeeds...
Cheers
Trond
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
@ 2009-08-21 17:50 ` Chuck Lever
0 siblings, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 17:50 UTC (permalink / raw)
To: Wu Fengguang; +Cc: Trond Myklebust, NFS list, LKML
On Aug 20, 2009, at 10:36 PM, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>> Hi,
>>>>
>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>> failed:
>>>>
>>>> # mount -t nfs pxe:/cc /cc
>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>
>>>> # uname -a
>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>
>>>> However server log says OK:
>>>>
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>
>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>> always been 2.6.30.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Fengguang
>>>
>>> Can you try again after enabling mount debugging on the NFS client?
>>>
>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>
>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>
>> dfprintk(MOUNT, "NFS: server does not support requested auth
>> flavor\ n");
>> nfs_umount(request);
>
> Thanks Fengguang!
>
> Chuck, this looks like one of yours. Could it be that you are hitting
> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
> AFAICR, the problem was that existing nfs servers do not set a default
> auth flavour, and so you just have to try with auth_sys and see if it
> succeeds...
With 1024 set, the mount client's XDR routines should have listed the
server's flavors, if any, in the system log. Should be something like
"NFS: received 0 auth flavors" if the server didn't return any. Can
you confirm that?
I'll try to post a fix later today.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
@ 2009-08-21 17:50 ` Chuck Lever
0 siblings, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 17:50 UTC (permalink / raw)
To: Wu Fengguang; +Cc: Trond Myklebust, NFS list, LKML
On Aug 20, 2009, at 10:36 PM, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>> Hi,
>>>>
>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>> failed:
>>>>
>>>> # mount -t nfs pxe:/cc /cc
>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>
>>>> # uname -a
>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>
>>>> However server log says OK:
>>>>
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>
>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>> always been 2.6.30.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Fengguang
>>>
>>> Can you try again after enabling mount debugging on the NFS client?
>>>
>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>
>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>
>> dfprintk(MOUNT, "NFS: server does not support requested auth
>> flavor\ n");
>> nfs_umount(request);
>
> Thanks Fengguang!
>
> Chuck, this looks like one of yours. Could it be that you are hitting
> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
> AFAICR, the problem was that existing nfs servers do not set a default
> auth flavour, and so you just have to try with auth_sys and see if it
> succeeds...
With 1024 set, the mount client's XDR routines should have listed the
server's flavors, if any, in the system log. Should be something like
"NFS: received 0 auth flavors" if the server didn't return any. Can
you confirm that?
I'll try to post a fix later today.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Fwd: mount.nfs: access denied by server
2009-08-21 2:36 ` Trond Myklebust
2009-08-21 17:50 ` Chuck Lever
@ 2009-08-21 18:16 ` Chuck Lever
2009-08-21 18:20 ` J. Bruce Fields
2009-08-21 18:24 ` J. Bruce Fields
1 sibling, 2 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 18:16 UTC (permalink / raw)
To: Trond Myklebust, Bruce Fields; +Cc: NFS list, Tom Haynes
I want to understand the server bug a little more. I glanced over RFC
2623 and didn't see anything specific.
Is it the case that only Linux NFSD does this, or do other servers do
it? In other words, is this a typical server response, and if so, is
there a specific semantic attached to it?
If no list is provided, should the client assume that only AUTH_NONE
and AUTH_SYS are supported, or instead, perhaps that the client can
try to use any flavor? In other words, if no list is provided, let
the mount proceed no matter what was specified by sec= ?
Thanks for any clarification.
Begin forwarded message:
> From: Trond Myklebust <trond.myklebust@fys.uio.no>
> Date: August 20, 2009 10:36:11 PM GMT-04:00
> To: Wu Fengguang <fengguang.wu@intel.com>, "Mr. Charles Edward
> Lever" <Chuck.Lever@oracle.com>
> Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org
> >
> Subject: Re: mount.nfs: access denied by server
>
> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>> Hi,
>>>>
>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>> failed:
>>>>
>>>> # mount -t nfs pxe:/cc /cc
>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>
>>>> # uname -a
>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>
>>>> However server log says OK:
>>>>
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>
>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>> always been 2.6.30.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Fengguang
>>>
>>> Can you try again after enabling mount debugging on the NFS client?
>>>
>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>
>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>
>> dfprintk(MOUNT, "NFS: server does not support requested auth
>> flavor\ n");
>> nfs_umount(request);
>
> Thanks Fengguang!
>
> Chuck, this looks like one of yours. Could it be that you are hitting
> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
> AFAICR, the problem was that existing nfs servers do not set a default
> auth flavour, and so you just have to try with auth_sys and see if it
> succeeds...
>
> Cheers
> Trond
>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Fwd: mount.nfs: access denied by server
2009-08-21 18:16 ` Fwd: " Chuck Lever
@ 2009-08-21 18:20 ` J. Bruce Fields
2009-08-21 20:20 ` Chuck Lever
2009-08-24 12:15 ` Fwd: " Steve Dickson
2009-08-21 18:24 ` J. Bruce Fields
1 sibling, 2 replies; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-21 18:20 UTC (permalink / raw)
To: Chuck Lever; +Cc: Trond Myklebust, NFS list, Tom Haynes, Steve Dickson
On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
> I want to understand the server bug a little more. I glanced over RFC
> 2623 and didn't see anything specific.
>
> Is it the case that only Linux NFSD does this, or do other servers do
> it? In other words, is this a typical server response, and if so, is
> there a specific semantic attached to it?
>
> If no list is provided, should the client assume that only AUTH_NONE and
> AUTH_SYS are supported, or instead, perhaps that the client can try to
> use any flavor? In other words, if no list is provided, let the mount
> proceed no matter what was specified by sec= ?
I've sent the following to Steve to fix the server bug.
--b.
commit ceb3c96d68f47cf6a0c38ccd88b98c59c886e9fb
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Tue Jul 21 19:30:04 2009 -0400
Don't give client an empty flavor list
In the absence of an explicit sec= option on an export, rpc.mountd is
returning a zero-length flavor list to clients in the MOUNT results.
The linux client doesn't seem to mind, but the Solaris client
(reasonably enough) is giving up; the symptom is a "security mode does
not match" error on mount.
We could modify the export-parsing code to ensure the secinfo array is
nonzero. But I think it's slightly simpler to handle this default case
in the implementation of the MOUNT call. This is more-or-less the same
thing the kernel does when mountd passes it an export without any
security flavors specified.
Thanks to Tom Haynes for bug report and diagnosis.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index b59f939..888fd8c 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok *ok, nfs_export *exp)
flavors[i] = s->flav->fnum;
i++;
}
+ if (i == 0) {
+ /* default when there is no sec= option: */
+ i = 1;
+ flavors[0] = AUTH_UNIX;
+ }
ok->auth_flavors.auth_flavors_val = flavors;
ok->auth_flavors.auth_flavors_len = i;
}
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: Fwd: mount.nfs: access denied by server
2009-08-21 18:16 ` Fwd: " Chuck Lever
2009-08-21 18:20 ` J. Bruce Fields
@ 2009-08-21 18:24 ` J. Bruce Fields
2009-08-21 18:46 ` Chuck Lever
2009-08-21 19:07 ` Thomas Haynes
1 sibling, 2 replies; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-21 18:24 UTC (permalink / raw)
To: Chuck Lever; +Cc: Trond Myklebust, NFS list, Tom Haynes
On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
> I want to understand the server bug a little more. I glanced over RFC
> 2623 and didn't see anything specific.
>
> Is it the case that only Linux NFSD does this, or do other servers do
> it? In other words, is this a typical server response, and if so, is
> there a specific semantic attached to it?
>
> If no list is provided, should the client assume that only AUTH_NONE and
> AUTH_SYS are supported, or instead, perhaps that the client can try to
> use any flavor? In other words, if no list is provided, let the mount
> proceed no matter what was specified by sec= ?
I think the safest behavior on the client would be something like:
- If an explicit sec= is provided on the client, try that
flavor. Otherwise:
- If the server returned a nonempty list, pick something
off that list. Otherwise:
- Try auth_sys.
--b.
>
> Thanks for any clarification.
>
> Begin forwarded message:
>
>> From: Trond Myklebust <trond.myklebust@fys.uio.no>
>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>> To: Wu Fengguang <fengguang.wu@intel.com>, "Mr. Charles Edward Lever"
>> <Chuck.Lever@oracle.com>
>> Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, LKML
>> <linux-kernel@vger.kernel.org>
>> Subject: Re: mount.nfs: access denied by server
>>
>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>> Hi,
>>>>>
>>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>>> failed:
>>>>>
>>>>> # mount -t nfs pxe:/cc /cc
>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>
>>>>> # uname -a
>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>
>>>>> However server log says OK:
>>>>>
>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>
>>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>>> always been 2.6.30.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Thanks,
>>>>> Fengguang
>>>>
>>>> Can you try again after enabling mount debugging on the NFS client?
>>>>
>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>
>>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>>
>>> dfprintk(MOUNT, "NFS: server does not support requested auth
>>> flavor\ n");
>>> nfs_umount(request);
>>
>> Thanks Fengguang!
>>
>> Chuck, this looks like one of yours. Could it be that you are hitting
>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
>> AFAICR, the problem was that existing nfs servers do not set a default
>> auth flavour, and so you just have to try with auth_sys and see if it
>> succeeds...
>>
>> Cheers
>> Trond
>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 18:24 ` J. Bruce Fields
@ 2009-08-21 18:46 ` Chuck Lever
2009-08-21 20:04 ` J. Bruce Fields
2009-08-21 19:07 ` Thomas Haynes
1 sibling, 1 reply; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 18:46 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Trond Myklebust, NFS list, Tom Haynes
On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>> I want to understand the server bug a little more. I glanced over
>> RFC
>> 2623 and didn't see anything specific.
>>
>> Is it the case that only Linux NFSD does this, or do other servers do
>> it? In other words, is this a typical server response, and if so, is
>> there a specific semantic attached to it?
>>
>> If no list is provided, should the client assume that only
>> AUTH_NONE and
>> AUTH_SYS are supported, or instead, perhaps that the client can try
>> to
>> use any flavor? In other words, if no list is provided, let the
>> mount
>> proceed no matter what was specified by sec= ?
>
> I think the safest behavior on the client would be something like:
>
> - If an explicit sec= is provided on the client, try that
> flavor. Otherwise:
> - If the server returned a nonempty list, pick something
> off that list. Otherwise:
> - Try auth_sys.
Right now, we use AUTH_SYS if the mount command didn't specify a
flavor, but the flavor we're going to use is always checked against
the server's returned list. You seem to be suggesting we should
ignore the server's list entirely if sec= was specified...?
>
> --b.
>
>>
>> Thanks for any clarification.
>>
>> Begin forwarded message:
>>
>>> From: Trond Myklebust <trond.myklebust@fys.uio.no>
>>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>>> To: Wu Fengguang <fengguang.wu@intel.com>, "Mr. Charles Edward
>>> Lever"
>>> <Chuck.Lever@oracle.com>
>>> Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, LKML
>>> <linux-kernel@vger.kernel.org>
>>> Subject: Re: mount.nfs: access denied by server
>>>
>>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>>>> failed:
>>>>>>
>>>>>> # mount -t nfs pxe:/cc /cc
>>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>>
>>>>>> # uname -a
>>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>>
>>>>>> However server log says OK:
>>>>>>
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>>
>>>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>>>> always been 2.6.30.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Fengguang
>>>>>
>>>>> Can you try again after enabling mount debugging on the NFS
>>>>> client?
>>>>>
>>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>>
>>>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>>>
>>>> dfprintk(MOUNT, "NFS: server does not support requested auth
>>>> flavor\ n");
>>>> nfs_umount(request);
>>>
>>> Thanks Fengguang!
>>>
>>> Chuck, this looks like one of yours. Could it be that you are
>>> hitting
>>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
>>> AFAICR, the problem was that existing nfs servers do not set a
>>> default
>>> auth flavour, and so you just have to try with auth_sys and see if
>>> it
>>> succeeds...
>>>
>>> Cheers
>>> Trond
>>>
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 18:24 ` J. Bruce Fields
2009-08-21 18:46 ` Chuck Lever
@ 2009-08-21 19:07 ` Thomas Haynes
[not found] ` <760BE185-BE57-42C2-817C-6776B5B66667-xsfywfwIY+M@public.gmane.org>
1 sibling, 1 reply; 55+ messages in thread
From: Thomas Haynes @ 2009-08-21 19:07 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Chuck Lever, Trond Myklebust, NFS list
Sent from my iPhone
On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields" <bfields@fieldses.org>
wrote:
> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>> I want to understand the server bug a little more. I glanced over
>> RFC
>> 2623 and didn't see anything specific.
>>
>> Is it the case that only Linux NFSD does this, or do other servers do
>> it? In other words, is this a typical server response, and if so, is
>> there a specific semantic attached to it?
>>
>> If no list is provided, should the client assume that only
>> AUTH_NONE and
>> AUTH_SYS are supported, or instead, perhaps that the client can try
>> to
>> use any flavor? In other words, if no list is provided, let the
>> mount
>> proceed no matter what was specified by sec= ?
>
> I think the safest behavior on the client would be something like:
>
> - If an explicit sec= is provided on the client, try that
> flavor. Otherwise:
> - If the server returned a nonempty list, pick something
> off that list. Otherwise:
> - Try auth_sys.
>
Which is pretty much what we do. The exception being that the default
flavor is a setting - and probably always AUTH_SYS...
> --b.
>
>>
>> Thanks for any clarification.
>>
>> Begin forwarded message:
>>
>>> From: Trond Myklebust <trond.myklebust@fys.uio.no>
>>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>>> To: Wu Fengguang <fengguang.wu@intel.com>, "Mr. Charles Edward
>>> Lever"
>>> <Chuck.Lever@oracle.com>
>>> Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, LKML
>>> <linux-kernel@vger.kernel.org>
>>> Subject: Re: mount.nfs: access denied by server
>>>
>>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After upgrading NFS client kernel to latest linux-next, NFS mount
>>>>>> failed:
>>>>>>
>>>>>> # mount -t nfs pxe:/cc /cc
>>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>>
>>>>>> # uname -a
>>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>>
>>>>>> However server log says OK:
>>>>>>
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>>
>>>>>> However-2: nfsroot can be mounted at boot time. Server kernel has
>>>>>> always been 2.6.30.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Fengguang
>>>>>
>>>>> Can you try again after enabling mount debugging on the NFS
>>>>> client?
>>>>>
>>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>>
>>>> I used 1024 and found the mount failed here in nfs_walk_authlist():
>>>>
>>>> dfprintk(MOUNT, "NFS: server does not support requested auth
>>>> flavor\ n");
>>>> nfs_umount(request);
>>>
>>> Thanks Fengguang!
>>>
>>> Chuck, this looks like one of yours. Could it be that you are
>>> hitting
>>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
>>> AFAICR, the problem was that existing nfs servers do not set a
>>> default
>>> auth flavour, and so you just have to try with auth_sys and see if
>>> it
>>> succeeds...
>>>
>>> Cheers
>>> Trond
>>>
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <760BE185-BE57-42C2-817C-6776B5B66667-xsfywfwIY+M@public.gmane.org>
@ 2009-08-21 19:22 ` Chuck Lever
2009-08-21 19:40 ` Tom Haynes
2009-08-21 20:41 ` Peter Staubach
0 siblings, 2 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 19:22 UTC (permalink / raw)
To: Thomas Haynes, J. Bruce Fields; +Cc: Trond Myklebust, NFS list
On Aug 21, 2009, at 3:07 PM, Thomas Haynes wrote:
> Sent from my iPhone
>
> On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields" =20
> <bfields@fieldses.org> wrote:
>
>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>> I want to understand the server bug a little more. I glanced over =
=20
>>> RFC
>>> 2623 and didn't see anything specific.
>>>
>>> Is it the case that only Linux NFSD does this, or do other servers =
=20
>>> do
>>> it? In other words, is this a typical server response, and if so, =
=20
>>> is
>>> there a specific semantic attached to it?
>>>
>>> If no list is provided, should the client assume that only =20
>>> AUTH_NONE and
>>> AUTH_SYS are supported, or instead, perhaps that the client can =20
>>> try to
>>> use any flavor? In other words, if no list is provided, let the =20
>>> mount
>>> proceed no matter what was specified by sec=3D ?
>>
>> I think the safest behavior on the client would be something like:
>>
>> - If an explicit sec=3D is provided on the client, try that
>> flavor. Otherwise:
>> - If the server returned a nonempty list, pick something
>> off that list. Otherwise:
>> - Try auth_sys.
>>
>
> Which is pretty much what we do. The exception being that the =20
> default flavor is a setting - and probably always AUTH_SYS...
I'm still not sure what is the right thing to do here. Looking at =20
1813, it says:
DESCRIPTION
Procedure MNT maps a pathname on the server to a file
handle. The pathname is an ASCII string that describes a
directory on the server. If the call is successful
(MNT3_OK), the server returns an NFS version 3 protocol
-> file handle and a vector of RPC authentication flavors
-> that are supported with the client=92s use of the file
-> handle (or any file handles derived from it). The
authentication flavors are defined in Section 7.2 and
section 9 of [RFC1057].
IMPLEMENTATION
If mountres3.fhs_status is MNT3_OK, then
mountres3.mountinfo contains the file handle for the
-> directory and a list of acceptable authentication
-> flavors. This file handle may only be used in the NFS
version 3 protocol. This procedure also results in the
server adding a new entry to its mount list recording that
this client has mounted the directory. AUTH_UNIX
authentication or better is required.
This suggests pretty clearly that the client should treat the returned =
=20
auth flavor list as the list of flavors supported for this mount =20
point, not as a preference list to be used only if the client is =20
trying to guess what flavor to use. Is my reading incorrect? =20
Help! :-)
>
>
>
>> --b.
>>
>>>
>>> Thanks for any clarification.
>>>
>>> Begin forwarded message:
>>>
>>>> From: Trond Myklebust <trond.myklebust@fys.uio.no>
>>>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>>>> To: Wu Fengguang <fengguang.wu@intel.com>, "Mr. Charles Edward =20
>>>> Lever"
>>>> <Chuck.Lever@oracle.com>
>>>> Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, LKML
>>>> <linux-kernel@vger.kernel.org>
>>>> Subject: Re: mount.nfs: access denied by server
>>>>
>>>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> After upgrading NFS client kernel to latest linux-next, NFS =20
>>>>>>> mount
>>>>>>> failed:
>>>>>>>
>>>>>>> # mount -t nfs pxe:/cc /cc
>>>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>>>
>>>>>>> # uname -a
>>>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>>>
>>>>>>> However server log says OK:
>>>>>>>
>>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
>>>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>>>
>>>>>>> However-2: nfsroot can be mounted at boot time. Server kernel =20
>>>>>>> has
>>>>>>> always been 2.6.30.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Fengguang
>>>>>>
>>>>>> Can you try again after enabling mount debugging on the NFS =20
>>>>>> client?
>>>>>>
>>>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>>>
>>>>> I used 1024 and found the mount failed here in =20
>>>>> nfs_walk_authlist():
>>>>>
>>>>> dfprintk(MOUNT, "NFS: server does not support requested auth
>>>>> flavor\ n");
>>>>> nfs_umount(request);
>>>>
>>>> Thanks Fengguang!
>>>>
>>>> Chuck, this looks like one of yours. Could it be that you are =20
>>>> hitting
>>>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client=
?
>>>> AFAICR, the problem was that existing nfs servers do not set a =20
>>>> default
>>>> auth flavour, and so you just have to try with auth_sys and see =20
>>>> if it
>>>> succeeds...
>>>>
>>>> Cheers
>>>> Trond
>>>>
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 19:22 ` Chuck Lever
@ 2009-08-21 19:40 ` Tom Haynes
[not found] ` <4A8EF847.8030500-xsfywfwIY+M@public.gmane.org>
2009-08-21 20:41 ` Peter Staubach
1 sibling, 1 reply; 55+ messages in thread
From: Tom Haynes @ 2009-08-21 19:40 UTC (permalink / raw)
To: Chuck Lever; +Cc: J. Bruce Fields, Trond Myklebust, NFS list
Chuck Lever wrote:
> On Aug 21, 2009, at 3:07 PM, Thomas Haynes wrote:
>> Sent from my iPhone
>>
>> On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields" <bfields@fieldses.org>
>> wrote:
>>
>>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>>> I want to understand the server bug a little more. I glanced over RFC
>>>> 2623 and didn't see anything specific.
>>>>
>>>> Is it the case that only Linux NFSD does this, or do other servers do
>>>> it? In other words, is this a typical server response, and if so, is
>>>> there a specific semantic attached to it?
>>>>
>>>> If no list is provided, should the client assume that only
>>>> AUTH_NONE and
>>>> AUTH_SYS are supported, or instead, perhaps that the client can try to
>>>> use any flavor? In other words, if no list is provided, let the mount
>>>> proceed no matter what was specified by sec= ?
>>>
>>> I think the safest behavior on the client would be something like:
>>>
>>> - If an explicit sec= is provided on the client, try that
>>> flavor. Otherwise:
>>> - If the server returned a nonempty list, pick something
>>> off that list. Otherwise:
>>> - Try auth_sys.
>>>
>>
>> Which is pretty much what we do. The exception being that the default
>> flavor is a setting - and probably always AUTH_SYS...
>
> I'm still not sure what is the right thing to do here. Looking at
> 1813, it says:
Sorry, I read this wrong, I thought the question was how should the
client handle
security flavors from the mount command.
With respect to the server returning a list, our implementation does
look at the list
of returned flavors and only tries to use one in the list. That was
actually the fix that
Bruce just applied - the linux server was returning an empty list and
the OpenSolaris
server would fail the mount.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 18:46 ` Chuck Lever
@ 2009-08-21 20:04 ` J. Bruce Fields
2009-08-21 20:18 ` Tom Haynes
2009-08-21 20:36 ` Chuck Lever
0 siblings, 2 replies; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-21 20:04 UTC (permalink / raw)
To: Chuck Lever; +Cc: Trond Myklebust, NFS list, Tom Haynes
On Fri, Aug 21, 2009 at 02:46:28PM -0400, Chuck Lever wrote:
> On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>> I want to understand the server bug a little more. I glanced over
>>> RFC
>>> 2623 and didn't see anything specific.
>>>
>>> Is it the case that only Linux NFSD does this, or do other servers do
>>> it? In other words, is this a typical server response, and if so, is
>>> there a specific semantic attached to it?
>>>
>>> If no list is provided, should the client assume that only AUTH_NONE
>>> and
>>> AUTH_SYS are supported, or instead, perhaps that the client can try
>>> to
>>> use any flavor? In other words, if no list is provided, let the
>>> mount
>>> proceed no matter what was specified by sec= ?
>>
>> I think the safest behavior on the client would be something like:
>>
>> - If an explicit sec= is provided on the client, try that
>> flavor. Otherwise:
>> - If the server returned a nonempty list, pick something
>> off that list. Otherwise:
>> - Try auth_sys.
>
> Right now, we use AUTH_SYS if the mount command didn't specify a flavor,
> but the flavor we're going to use is always checked against the server's
> returned list. You seem to be suggesting we should ignore the server's
> list entirely if sec= was specified...?
Yes. I can't see what practical problems that would cause.
Also, while I hope this is the last bug in the mountd's flavor list
return, it isn't the first--only recently did we even start using real
information from the export instead of just faking something up. So I
think it's safest to preserve the historical sec= behavior and give
users a way to override the negotiation, to cut down on bug reports of
mount failures on upgrade.
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <4A8EF847.8030500-xsfywfwIY+M@public.gmane.org>
@ 2009-08-21 20:04 ` Chuck Lever
0 siblings, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 20:04 UTC (permalink / raw)
To: Tom Haynes; +Cc: J. Bruce Fields, Trond Myklebust, NFS list
On Aug 21, 2009, at 3:40 PM, Tom Haynes wrote:
> Chuck Lever wrote:
>> On Aug 21, 2009, at 3:07 PM, Thomas Haynes wrote:
>>> Sent from my iPhone
>>>
>>> On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields"
>>> <bfields@fieldses.org> wrote:
>>>
>>>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>>>> I want to understand the server bug a little more. I glanced
>>>>> over RFC
>>>>> 2623 and didn't see anything specific.
>>>>>
>>>>> Is it the case that only Linux NFSD does this, or do other
>>>>> servers do
>>>>> it? In other words, is this a typical server response, and if
>>>>> so, is
>>>>> there a specific semantic attached to it?
>>>>>
>>>>> If no list is provided, should the client assume that only
>>>>> AUTH_NONE and
>>>>> AUTH_SYS are supported, or instead, perhaps that the client can
>>>>> try to
>>>>> use any flavor? In other words, if no list is provided, let the
>>>>> mount
>>>>> proceed no matter what was specified by sec= ?
>>>>
>>>> I think the safest behavior on the client would be something like:
>>>>
>>>> - If an explicit sec= is provided on the client, try that
>>>> flavor. Otherwise:
>>>> - If the server returned a nonempty list, pick something
>>>> off that list. Otherwise:
>>>> - Try auth_sys.
>>>>
>>>
>>> Which is pretty much what we do. The exception being that the
>>> default flavor is a setting - and probably always AUTH_SYS...
>>
>> I'm still not sure what is the right thing to do here. Looking at
>> 1813, it says:
>
> Sorry, I read this wrong, I thought the question was how should the
> client handle
> security flavors from the mount command.
>
> With respect to the server returning a list, our implementation does
> look at the list
> of returned flavors and only tries to use one in the list. That was
> actually the fix that
> Bruce just applied - the linux server was returning an empty list
> and the OpenSolaris
> server would fail the mount.
Thanks.
Do we know if other server implementations neglect to return a flavor
list? If it's only Linux, I guess it's reasonable for the client to
assume the server supports AUTH_SYS in that case.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 20:04 ` J. Bruce Fields
@ 2009-08-21 20:18 ` Tom Haynes
[not found] ` <4A8F0118.60705-xsfywfwIY+M@public.gmane.org>
2009-08-21 20:36 ` Chuck Lever
1 sibling, 1 reply; 55+ messages in thread
From: Tom Haynes @ 2009-08-21 20:18 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Chuck Lever, Trond Myklebust, NFS list
J. Bruce Fields wrote:
>
>> Right now, we use AUTH_SYS if the mount command didn't specify a flavor,
>> but the flavor we're going to use is always checked against the server's
>> returned list. You seem to be suggesting we should ignore the server's
>> list entirely if sec= was specified...?
>>
>
> Yes. I can't see what practical problems that would cause.
>
> Also, while I hope this is the last bug in the mountd's flavor list
> return, it isn't the first--only recently did we even start using real
> information from the export instead of just faking something up. So I
> think it's safest to preserve the historical sec= behavior and give
> users a way to override the negotiation, to cut down on bug reports of
> mount failures on upgrade.
>
> --b.
>
While this Linux behavior occasionally bites the OpenSolaris behavior, it
really means we just have to guard against the client ignoring what we sent.
I.e., if I say we only support krb5 and you try with AUTH_SYS, I should
reject it.
Historical inertia is hard to overcome, but perhaps you could gradually
ease your way into using the real data. :->
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 18:20 ` J. Bruce Fields
@ 2009-08-21 20:20 ` Chuck Lever
2009-08-24 12:15 ` Fwd: " Steve Dickson
1 sibling, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 20:20 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Trond Myklebust, NFS list, Tom Haynes, Steve Dickson
On Aug 21, 2009, at 2:20 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>> I want to understand the server bug a little more. I glanced over
>> RFC
>> 2623 and didn't see anything specific.
>>
>> Is it the case that only Linux NFSD does this, or do other servers do
>> it? In other words, is this a typical server response, and if so, is
>> there a specific semantic attached to it?
>>
>> If no list is provided, should the client assume that only
>> AUTH_NONE and
>> AUTH_SYS are supported, or instead, perhaps that the client can try
>> to
>> use any flavor? In other words, if no list is provided, let the
>> mount
>> proceed no matter what was specified by sec= ?
>
> I've sent the following to Steve to fix the server bug.
>
> --b.
>
> commit ceb3c96d68f47cf6a0c38ccd88b98c59c886e9fb
> Author: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Tue Jul 21 19:30:04 2009 -0400
>
> Don't give client an empty flavor list
>
> In the absence of an explicit sec= option on an export,
> rpc.mountd is
> returning a zero-length flavor list to clients in the MOUNT
> results.
>
> The linux client doesn't seem to mind, but the Solaris client
> (reasonably enough) is giving up; the symptom is a "security mode
> does
> not match" error on mount.
>
> We could modify the export-parsing code to ensure the secinfo
> array is
> nonzero. But I think it's slightly simpler to handle this
> default case
> in the implementation of the MOUNT call. This is more-or-less
> the same
> thing the kernel does when mountd passes it an export without any
> security flavors specified.
>
> Thanks to Tom Haynes for bug report and diagnosis.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
>
> diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
> index b59f939..888fd8c 100644
> --- a/utils/mountd/mountd.c
> +++ b/utils/mountd/mountd.c
> @@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok
> *ok, nfs_export *exp)
> flavors[i] = s->flav->fnum;
> i++;
> }
> + if (i == 0) {
> + /* default when there is no sec= option: */
> + i = 1;
> + flavors[0] = AUTH_UNIX;
> + }
Does the Linux server also support AUTH_NONE if sec= isn't specified?
> ok->auth_flavors.auth_flavors_val = flavors;
> ok->auth_flavors.auth_flavors_len = i;
> }
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 20:04 ` J. Bruce Fields
2009-08-21 20:18 ` Tom Haynes
@ 2009-08-21 20:36 ` Chuck Lever
2009-08-21 21:15 ` Trond Myklebust
1 sibling, 1 reply; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 20:36 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Trond Myklebust, NFS list, Tom Haynes
On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 02:46:28PM -0400, Chuck Lever wrote:
>> On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
>>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>>> I want to understand the server bug a little more. I glanced over
>>>> RFC
>>>> 2623 and didn't see anything specific.
>>>>
>>>> Is it the case that only Linux NFSD does this, or do other
>>>> servers do
>>>> it? In other words, is this a typical server response, and if
>>>> so, is
>>>> there a specific semantic attached to it?
>>>>
>>>> If no list is provided, should the client assume that only
>>>> AUTH_NONE
>>>> and
>>>> AUTH_SYS are supported, or instead, perhaps that the client can try
>>>> to
>>>> use any flavor? In other words, if no list is provided, let the
>>>> mount
>>>> proceed no matter what was specified by sec= ?
>>>
>>> I think the safest behavior on the client would be something like:
>>>
>>> - If an explicit sec= is provided on the client, try that
>>> flavor. Otherwise:
>>> - If the server returned a nonempty list, pick something
>>> off that list. Otherwise:
>>> - Try auth_sys.
>>
>> Right now, we use AUTH_SYS if the mount command didn't specify a
>> flavor,
>> but the flavor we're going to use is always checked against the
>> server's
>> returned list. You seem to be suggesting we should ignore the
>> server's
>> list entirely if sec= was specified...?
>
> Yes. I can't see what practical problems that would cause.
Well, it would mean our client isn't up to spec, confusing people who
need to modify that code and people who expect a sec=krb5 mount to
fail immediately if the server says it can't support AUTH_GSS_KRB5.
It may also not match the behavior of the legacy mount command on Linux.
> Also, while I hope this is the last bug in the mountd's flavor list
> return, it isn't the first--only recently did we even start using real
> information from the export instead of just faking something up. So I
> think it's safest to preserve the historical sec= behavior and give
> users a way to override the negotiation, to cut down on bug reports of
> mount failures on upgrade.
OK, if this is a recently introduced server problem, then why do we
need to adjust client-side behavior? Trond's response in cases like
this is usually "fix the d*mn server," which you've already done.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <4A8F0118.60705-xsfywfwIY+M@public.gmane.org>
@ 2009-08-21 20:39 ` Peter Staubach
2009-08-21 20:59 ` J. Bruce Fields
0 siblings, 1 reply; 55+ messages in thread
From: Peter Staubach @ 2009-08-21 20:39 UTC (permalink / raw)
To: Tom Haynes; +Cc: J. Bruce Fields, Chuck Lever, Trond Myklebust, NFS list
Tom Haynes wrote:
> J. Bruce Fields wrote:
>>
>>> Right now, we use AUTH_SYS if the mount command didn't specify a
>>> flavor, but the flavor we're going to use is always checked against
>>> the server's returned list. You seem to be suggesting we should
>>> ignore the server's list entirely if sec= was specified...?
>>>
>>
>> Yes. I can't see what practical problems that would cause.
>>
Here, I am going to disagree. The client should compare the
flavor specified with the list of authentication flavors
returned by the server and if the specific flavor isn't on
the list, then the mount attempt should be failed.
>> Also, while I hope this is the last bug in the mountd's flavor list
>> return, it isn't the first--only recently did we even start using real
>> information from the export instead of just faking something up. So I
>> think it's safest to preserve the historical sec= behavior and give
>> users a way to override the negotiation, to cut down on bug reports of
>> mount failures on upgrade.
>>
>> --b.
>>
>
>
> While this Linux behavior occasionally bites the OpenSolaris behavior, it
> really means we just have to guard against the client ignoring what we
> sent.
> I.e., if I say we only support krb5 and you try with AUTH_SYS, I should
> reject it.
>
Which should happen correctly, right?
ps
> Historical inertia is hard to overcome, but perhaps you could gradually
> ease your way into using the real data. :->
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 19:22 ` Chuck Lever
2009-08-21 19:40 ` Tom Haynes
@ 2009-08-21 20:41 ` Peter Staubach
1 sibling, 0 replies; 55+ messages in thread
From: Peter Staubach @ 2009-08-21 20:41 UTC (permalink / raw)
To: Chuck Lever; +Cc: Thomas Haynes, J. Bruce Fields, Trond Myklebust, NFS list
Chuck Lever wrote:
> On Aug 21, 2009, at 3:07 PM, Thomas Haynes wrote:
>> Sent from my iPhone
>>
>> On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields" <bfields@fieldses.org=
>
>> wrote:
>>
>>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
>>>> I want to understand the server bug a little more. I glanced over=
RFC
>>>> 2623 and didn't see anything specific.
>>>>
>>>> Is it the case that only Linux NFSD does this, or do other servers=
do
>>>> it? In other words, is this a typical server response, and if so,=
is
>>>> there a specific semantic attached to it?
>>>>
>>>> If no list is provided, should the client assume that only AUTH_NO=
NE
>>>> and
>>>> AUTH_SYS are supported, or instead, perhaps that the client can tr=
y to
>>>> use any flavor? In other words, if no list is provided, let the m=
ount
>>>> proceed no matter what was specified by sec=3D ?
>>>
>>> I think the safest behavior on the client would be something like:
>>>
>>> - If an explicit sec=3D is provided on the client, try that
>>> flavor. Otherwise:
>>> - If the server returned a nonempty list, pick something
>>> off that list. Otherwise:
>>> - Try auth_sys.
>>>
>>
>> Which is pretty much what we do. The exception being that the defaul=
t
>> flavor is a setting - and probably always AUTH_SYS...
>=20
> I'm still not sure what is the right thing to do here. Looking at 18=
13,
> it says:
>=20
> DESCRIPTION
> Procedure MNT maps a pathname on the server to a file
> handle. The pathname is an ASCII string that describes a
> directory on the server. If the call is successful
> (MNT3_OK), the server returns an NFS version 3 protocol
> -> file handle and a vector of RPC authentication flavors
> -> that are supported with the client=92s use of the file
> -> handle (or any file handles derived from it). The
> authentication flavors are defined in Section 7.2 and
> section 9 of [RFC1057].
>=20
> IMPLEMENTATION
> If mountres3.fhs_status is MNT3_OK, then
> mountres3.mountinfo contains the file handle for the
> -> directory and a list of acceptable authentication
> -> flavors. This file handle may only be used in the NFS
> version 3 protocol. This procedure also results in the
> server adding a new entry to its mount list recording that
> this client has mounted the directory. AUTH_UNIX
> authentication or better is required.
>=20
> This suggests pretty clearly that the client should treat the returne=
d
> auth flavor list as the list of flavors supported for this mount poin=
t,
> not as a preference list to be used only if the client is trying to
> guess what flavor to use. Is my reading incorrect? Help! :-)
>=20
Your interpretation is the correct one, Chuck. The list
returned from the server is supposed to be the definitive
list of authentication flavors that the server will accept
from the client.
A server which returns no flavors is by definition, broken.
ps
>=20
>>
>>
>>
>>> --b.
>>>
>>>>
>>>> Thanks for any clarification.
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Trond Myklebust <trond.myklebust@fys.uio.no>
>>>>> Date: August 20, 2009 10:36:11 PM GMT-04:00
>>>>> To: Wu Fengguang <fengguang.wu@intel.com>, "Mr. Charles Edward Le=
ver"
>>>>> <Chuck.Lever@oracle.com>
>>>>> Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, LKML
>>>>> <linux-kernel@vger.kernel.org>
>>>>> Subject: Re: mount.nfs: access denied by server
>>>>>
>>>>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
>>>>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
>>>>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> After upgrading NFS client kernel to latest linux-next, NFS mo=
unt
>>>>>>>> failed:
>>>>>>>>
>>>>>>>> # mount -t nfs pxe:/cc /cc
>>>>>>>> mount.nfs: access denied by server while mounting pxe:/cc
>>>>>>>>
>>>>>>>> # uname -a
>>>>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
>>>>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux
>>>>>>>>
>>>>>>>> However server log says OK:
>>>>>>>>
>>>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
>>>>>>>> request from 192.168.11.6:973 for /cc (/cc)
>>>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmoun=
t
>>>>>>>> request from 192.168.11.6:974 for /cc (/cc)
>>>>>>>>
>>>>>>>> However-2: nfsroot can be mounted at boot time. Server kernel =
has
>>>>>>>> always been 2.6.30.
>>>>>>>>
>>>>>>>> Any ideas?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Fengguang
>>>>>>>
>>>>>>> Can you try again after enabling mount debugging on the NFS cli=
ent?
>>>>>>>
>>>>>>> echo 512 > /proc/sys/sunrpc/nfs_debug
>>>>>>
>>>>>> I used 1024 and found the mount failed here in nfs_walk_authlist=
():
>>>>>>
>>>>>> dfprintk(MOUNT, "NFS: server does not support requested aut=
h
>>>>>> flavor\ n");
>>>>>> nfs_umount(request);
>>>>>
>>>>> Thanks Fengguang!
>>>>>
>>>>> Chuck, this looks like one of yours. Could it be that you are hit=
ting
>>>>> the same Linux knfsd bug that Tom Haynes saw with a Solaris clien=
t?
>>>>> AFAICR, the problem was that existing nfs servers do not set a de=
fault
>>>>> auth flavour, and so you just have to try with auth_sys and see i=
f it
>>>>> succeeds...
>>>>>
>>>>> Cheers
>>>>> Trond
>>>>>
>>>>
>>>> --=20
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>>
>=20
> --=20
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>=20
>=20
>=20
> --=20
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 20:39 ` Peter Staubach
@ 2009-08-21 20:59 ` J. Bruce Fields
2009-08-21 21:08 ` Trond Myklebust
0 siblings, 1 reply; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-21 20:59 UTC (permalink / raw)
To: Peter Staubach; +Cc: Tom Haynes, Chuck Lever, Trond Myklebust, NFS list
On Fri, Aug 21, 2009 at 04:39:53PM -0400, Peter Staubach wrote:
> Tom Haynes wrote:
> > J. Bruce Fields wrote:
> >>
> >>> Right now, we use AUTH_SYS if the mount command didn't specify a
> >>> flavor, but the flavor we're going to use is always checked against
> >>> the server's returned list. You seem to be suggesting we should
> >>> ignore the server's list entirely if sec= was specified...?
> >>>
> >>
> >> Yes. I can't see what practical problems that would cause.
> >>
>
> Here, I am going to disagree. The client should compare the
> flavor specified with the list of authentication flavors
> returned by the server and if the specific flavor isn't on
> the list, then the mount attempt should be failed.
Why? What can go wrong if you just try the flavor?
Ugh: to answer my own question: ok, if the server allows auth_sys for
the NFS operations required on mount (as suggested by the security
considerations rfc), then that would mean mount would always succeed,
and nobody would see the error until the first operation on the
filesystem. It would be better to return the error on mount.
So, I think I have to give in and agree with you. People will just have
to upgrade their mountd's....
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 20:59 ` J. Bruce Fields
@ 2009-08-21 21:08 ` Trond Myklebust
[not found] ` <1250888892.5700.7.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-21 21:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Peter Staubach, Tom Haynes, Chuck Lever, NFS list
On Fri, 2009-08-21 at 16:59 -0400, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 04:39:53PM -0400, Peter Staubach wrote:
> > Tom Haynes wrote:
> > > J. Bruce Fields wrote:
> > >>
> > >>> Right now, we use AUTH_SYS if the mount command didn't specify a
> > >>> flavor, but the flavor we're going to use is always checked against
> > >>> the server's returned list. You seem to be suggesting we should
> > >>> ignore the server's list entirely if sec= was specified...?
> > >>>
> > >>
> > >> Yes. I can't see what practical problems that would cause.
> > >>
> >
> > Here, I am going to disagree. The client should compare the
> > flavor specified with the list of authentication flavors
> > returned by the server and if the specific flavor isn't on
> > the list, then the mount attempt should be failed.
>
> Why? What can go wrong if you just try the flavor?
>
> Ugh: to answer my own question: ok, if the server allows auth_sys for
> the NFS operations required on mount (as suggested by the security
> considerations rfc), then that would mean mount would always succeed,
> and nobody would see the error until the first operation on the
> filesystem. It would be better to return the error on mount.
>
> So, I think I have to give in and agree with you. People will just have
> to upgrade their mountd's....
People have lived with the current situation for years without any
trouble. It was only the addition of the security negotiation that
exposed the mountd bug.
My position is that if mountd returns a clearly invalid (i.e. empty)
list, then that's not a reason to interrupt the mount. We should just
fall back to what we did prior to including security negotiation.
The alternative is simply not to merge security negotiation until people
have had ample time to upgrade mountd (i.e. 2-3 years from now).
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 20:36 ` Chuck Lever
@ 2009-08-21 21:15 ` Trond Myklebust
[not found] ` <1250889345.5700.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-21 21:15 UTC (permalink / raw)
To: Chuck Lever; +Cc: J. Bruce Fields, NFS list, Tom Haynes
On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
> On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> > Also, while I hope this is the last bug in the mountd's flavor list
> > return, it isn't the first--only recently did we even start using real
> > information from the export instead of just faking something up. So I
> > think it's safest to preserve the historical sec= behavior and give
> > users a way to override the negotiation, to cut down on bug reports of
> > mount failures on upgrade.
>
> OK, if this is a recently introduced server problem, then why do we
> need to adjust client-side behavior? Trond's response in cases like
> this is usually "fix the d*mn server," which you've already done.
What is the definition of "recently introduced" here? What is the exact
commit that introduced the bug in nfs-utils?
The problem is that we're changing the client, and if it turns out that
every damned Linux server that was installed out there in the past 2
years displays this bug, then Linus will call 'regression' on us and
revert the code.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1250889345.5700.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-21 21:21 ` Tom Haynes
[not found] ` <4A8F0FCC.2080709-xsfywfwIY+M@public.gmane.org>
2009-08-21 21:30 ` J. Bruce Fields
1 sibling, 1 reply; 55+ messages in thread
From: Tom Haynes @ 2009-08-21 21:21 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, J. Bruce Fields, NFS list
Trond Myklebust wrote:
> What is the definition of "recently introduced" here? What is the exact
> commit that introduced the bug in nfs-utils?
>
> The problem is that we're changing the client, and if it turns out that
> every damned Linux server that was installed out there in the past 2
> years displays this bug, then Linus will call 'regression' on us and
> revert the code.
>
> Trond
>
>
The Linux client and server have well defined behaviors in that they always
will default to AUTH_SYS.
It may not be standard compliant, but everyone and their dog knows it.
Newer servers will not hand out empty lists, and why cause yourself grief
by not handling older servers?
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1250888892.5700.7.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-21 21:21 ` J. Bruce Fields
0 siblings, 0 replies; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-21 21:21 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Peter Staubach, Tom Haynes, Chuck Lever, NFS list
On Fri, Aug 21, 2009 at 05:08:12PM -0400, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 16:59 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 21, 2009 at 04:39:53PM -0400, Peter Staubach wrote:
> > > Tom Haynes wrote:
> > > > J. Bruce Fields wrote:
> > > >>
> > > >>> Right now, we use AUTH_SYS if the mount command didn't specify a
> > > >>> flavor, but the flavor we're going to use is always checked against
> > > >>> the server's returned list. You seem to be suggesting we should
> > > >>> ignore the server's list entirely if sec= was specified...?
> > > >>>
> > > >>
> > > >> Yes. I can't see what practical problems that would cause.
> > > >>
> > >
> > > Here, I am going to disagree. The client should compare the
> > > flavor specified with the list of authentication flavors
> > > returned by the server and if the specific flavor isn't on
> > > the list, then the mount attempt should be failed.
> >
> > Why? What can go wrong if you just try the flavor?
> >
> > Ugh: to answer my own question: ok, if the server allows auth_sys for
> > the NFS operations required on mount (as suggested by the security
> > considerations rfc), then that would mean mount would always succeed,
> > and nobody would see the error until the first operation on the
> > filesystem. It would be better to return the error on mount.
> >
> > So, I think I have to give in and agree with you. People will just have
> > to upgrade their mountd's....
>
> People have lived with the current situation for years without any
> trouble. It was only the addition of the security negotiation that
> exposed the mountd bug.
>
> My position is that if mountd returns a clearly invalid (i.e. empty)
> list, then that's not a reason to interrupt the mount. We should just
> fall back to what we did prior to including security negotiation.
Yeah, so instead of taking my original pseudocode (which just allowed
sec= to always override even a non-empty list from the server), more
reasonable might be just to treat the empty-list case specially.
For example, maybe:
- If the returned list is nonempty:
- Do whatever the latest code does: probably return an
error if there's a clash with the sec= mount option,
otherwise attempt the first on the list.
- Otherwise, if the returned list is empty:
- Use any sec= option if provide, or auth_sys if not.
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <4A8F0FCC.2080709-xsfywfwIY+M@public.gmane.org>
@ 2009-08-21 21:25 ` Trond Myklebust
0 siblings, 0 replies; 55+ messages in thread
From: Trond Myklebust @ 2009-08-21 21:25 UTC (permalink / raw)
To: Tom Haynes; +Cc: Chuck Lever, J. Bruce Fields, NFS list
On Fri, 2009-08-21 at 16:21 -0500, Tom Haynes wrote:
> The Linux client and server have well defined behaviors in that they always
> will default to AUTH_SYS.
>
> It may not be standard compliant, but everyone and their dog knows it.
>
> Newer servers will not hand out empty lists, and why cause yourself grief
> by not handling older servers?
Particularly so when we used to handle those older servers well.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1250889345.5700.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-21 21:21 ` Tom Haynes
@ 2009-08-21 21:30 ` J. Bruce Fields
2009-08-21 21:40 ` Trond Myklebust
2009-08-21 21:41 ` Chuck Lever
1 sibling, 2 replies; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-21 21:30 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, NFS list, Tom Haynes
On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
> > On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> > > Also, while I hope this is the last bug in the mountd's flavor list
> > > return, it isn't the first--only recently did we even start using real
> > > information from the export instead of just faking something up. So I
> > > think it's safest to preserve the historical sec= behavior and give
> > > users a way to override the negotiation, to cut down on bug reports of
> > > mount failures on upgrade.
> >
> > OK, if this is a recently introduced server problem, then why do we
> > need to adjust client-side behavior? Trond's response in cases like
> > this is usually "fix the d*mn server," which you've already done.
>
> What is the definition of "recently introduced" here? What is the exact
> commit that introduced the bug in nfs-utils?
By the way, looking at 'gitk utils/mountd/mountd.c' in my tree:
Originally (didn't look to see how far it goes back), mountd
returned AUTH_NULL, AUTH_UNIX, in that order.
53c5bd65c74, first in 1.0.8, always returns
AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I,
AUTH_GSS_KRB5P, in that order.
3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
list.
603017f2c15, first in 1.1.4, derives the psuedoflavor list from
the export (and introduces the above bug).
The latest patch, not yet in Steve's repo, fixes the empty flavor
list.
For the rest of eternity, mountd is perfect.
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 21:30 ` J. Bruce Fields
@ 2009-08-21 21:40 ` Trond Myklebust
[not found] ` <1250890836.5700.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-21 21:41 ` Chuck Lever
1 sibling, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-21 21:40 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Chuck Lever, NFS list, Tom Haynes
On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote:
> > On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
> > > On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> > > > Also, while I hope this is the last bug in the mountd's flavor list
> > > > return, it isn't the first--only recently did we even start using real
> > > > information from the export instead of just faking something up. So I
> > > > think it's safest to preserve the historical sec= behavior and give
> > > > users a way to override the negotiation, to cut down on bug reports of
> > > > mount failures on upgrade.
> > >
> > > OK, if this is a recently introduced server problem, then why do we
> > > need to adjust client-side behavior? Trond's response in cases like
> > > this is usually "fix the d*mn server," which you've already done.
> >
> > What is the definition of "recently introduced" here? What is the exact
> > commit that introduced the bug in nfs-utils?
>
> By the way, looking at 'gitk utils/mountd/mountd.c' in my tree:
>
> Originally (didn't look to see how far it goes back), mountd
> returned AUTH_NULL, AUTH_UNIX, in that order.
> 53c5bd65c74, first in 1.0.8, always returns
> AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I,
> AUTH_GSS_KRB5P, in that order.
So all these should work without any trouble.
> 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> list.
Does the server support auth_null security? I didn't think it did.
> 603017f2c15, first in 1.1.4, derives the psuedoflavor list from
> the export (and introduces the above bug).
That means the bug is likely to be in Fedora 10 and 11, the latest
Debian and Ubuntu, as well as SLES 11. Sounds like a long list to me...
> The latest patch, not yet in Steve's repo, fixes the empty flavor
> list.
> For the rest of eternity, mountd is perfect.
We're getting rid of it?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 21:30 ` J. Bruce Fields
2009-08-21 21:40 ` Trond Myklebust
@ 2009-08-21 21:41 ` Chuck Lever
1 sibling, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 21:41 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Trond Myklebust, NFS list, Tom Haynes
On Aug 21, 2009, at 5:30 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote:
>> On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
>>> On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
>>>> Also, while I hope this is the last bug in the mountd's flavor list
>>>> return, it isn't the first--only recently did we even start using
>>>> real
>>>> information from the export instead of just faking something up.
>>>> So I
>>>> think it's safest to preserve the historical sec= behavior and give
>>>> users a way to override the negotiation, to cut down on bug
>>>> reports of
>>>> mount failures on upgrade.
>>>
>>> OK, if this is a recently introduced server problem, then why do we
>>> need to adjust client-side behavior? Trond's response in cases like
>>> this is usually "fix the d*mn server," which you've already done.
>>
>> What is the definition of "recently introduced" here? What is the
>> exact
>> commit that introduced the bug in nfs-utils?
>
> By the way, looking at 'gitk utils/mountd/mountd.c' in my tree:
>
> Originally (didn't look to see how far it goes back), mountd
> returned AUTH_NULL, AUTH_UNIX, in that order.
1999, at least. That's when nfs-utils was imported into a source
control system, which was later moved to git.
> 53c5bd65c74, first in 1.0.8, always returns
> AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I,
> AUTH_GSS_KRB5P, in that order.
> 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> list.
> 603017f2c15, first in 1.1.4, derives the psuedoflavor list from
> the export (and introduces the above bug).
1.1.4 was released October 14, 2008. I'm sure it was a month or two
before distributions picked it up.
> The latest patch, not yet in Steve's repo, fixes the empty flavor
> list.
> For the rest of eternity, mountd is perfect.
Having the client ignore flavor checking if the returned auth flavor
list is empty is easy. We should check the behavior of the legacy
mount command too.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1250890836.5700.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-21 21:47 ` J. Bruce Fields
2009-08-21 21:51 ` Trond Myklebust
2009-08-21 22:21 ` Chuck Lever
1 sibling, 1 reply; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-21 21:47 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, NFS list, Tom Haynes
On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote:
> > > On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
> > > > On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> > > > > Also, while I hope this is the last bug in the mountd's flavor list
> > > > > return, it isn't the first--only recently did we even start using real
> > > > > information from the export instead of just faking something up. So I
> > > > > think it's safest to preserve the historical sec= behavior and give
> > > > > users a way to override the negotiation, to cut down on bug reports of
> > > > > mount failures on upgrade.
> > > >
> > > > OK, if this is a recently introduced server problem, then why do we
> > > > need to adjust client-side behavior? Trond's response in cases like
> > > > this is usually "fix the d*mn server," which you've already done.
> > >
> > > What is the definition of "recently introduced" here? What is the exact
> > > commit that introduced the bug in nfs-utils?
> >
> > By the way, looking at 'gitk utils/mountd/mountd.c' in my tree:
> >
> > Originally (didn't look to see how far it goes back), mountd
> > returned AUTH_NULL, AUTH_UNIX, in that order.
> > 53c5bd65c74, first in 1.0.8, always returns
> > AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I,
> > AUTH_GSS_KRB5P, in that order.
>
> So all these should work without any trouble.
>
> > 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> > list.
>
> Does the server support auth_null security? I didn't think it did.
Just off the top of my head, without looking at the code: I believe it
treats auth_null rpc calls exactly as if they were auth_sys calls with
uid and gid set to the "anonymous" uid and gid.
>
> > 603017f2c15, first in 1.1.4, derives the psuedoflavor list from
> > the export (and introduces the above bug).
>
> That means the bug is likely to be in Fedora 10 and 11, the latest
> Debian and Ubuntu, as well as SLES 11. Sounds like a long list to me...
>
> > The latest patch, not yet in Steve's repo, fixes the empty flavor
> > list.
> > For the rest of eternity, mountd is perfect.
>
> We're getting rid of it?
Pfft, some people are such pessimists.
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 21:47 ` J. Bruce Fields
@ 2009-08-21 21:51 ` Trond Myklebust
[not found] ` <1250891463.5700.21.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-21 21:51 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Chuck Lever, NFS list, Tom Haynes
On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
> > On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
> > > On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote:
> > > > On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
> > > > > On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
> > > > > > Also, while I hope this is the last bug in the mountd's flavor list
> > > > > > return, it isn't the first--only recently did we even start using real
> > > > > > information from the export instead of just faking something up. So I
> > > > > > think it's safest to preserve the historical sec= behavior and give
> > > > > > users a way to override the negotiation, to cut down on bug reports of
> > > > > > mount failures on upgrade.
> > > > >
> > > > > OK, if this is a recently introduced server problem, then why do we
> > > > > need to adjust client-side behavior? Trond's response in cases like
> > > > > this is usually "fix the d*mn server," which you've already done.
> > > >
> > > > What is the definition of "recently introduced" here? What is the exact
> > > > commit that introduced the bug in nfs-utils?
> > >
> > > By the way, looking at 'gitk utils/mountd/mountd.c' in my tree:
> > >
> > > Originally (didn't look to see how far it goes back), mountd
> > > returned AUTH_NULL, AUTH_UNIX, in that order.
> > > 53c5bd65c74, first in 1.0.8, always returns
> > > AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I,
> > > AUTH_GSS_KRB5P, in that order.
> >
> > So all these should work without any trouble.
> >
> > > 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> > > list.
> >
> > Does the server support auth_null security? I didn't think it did.
>
> Just off the top of my head, without looking at the code: I believe it
> treats auth_null rpc calls exactly as if they were auth_sys calls with
> uid and gid set to the "anonymous" uid and gid.
OK, so that would break too.
> > > 603017f2c15, first in 1.1.4, derives the psuedoflavor list from
> > > the export (and introduces the above bug).
> >
> > That means the bug is likely to be in Fedora 10 and 11, the latest
> > Debian and Ubuntu, as well as SLES 11. Sounds like a long list to me...
> >
> > > The latest patch, not yet in Steve's repo, fixes the empty flavor
> > > list.
> > > For the rest of eternity, mountd is perfect.
> >
> > We're getting rid of it?
>
> Pfft, some people are such pessimists.
I'm the pessimist? You really had my hopes up...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1250890836.5700.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-21 21:47 ` J. Bruce Fields
@ 2009-08-21 22:21 ` Chuck Lever
1 sibling, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-21 22:21 UTC (permalink / raw)
To: Trond Myklebust; +Cc: J. Bruce Fields, NFS list, Tom Haynes
On Aug 21, 2009, at 5:40 PM, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
>> On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote:
>>> On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
>>>> On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
>>>>> Also, while I hope this is the last bug in the mountd's flavor
>>>>> list
>>>>> return, it isn't the first--only recently did we even start
>>>>> using real
>>>>> information from the export instead of just faking something
>>>>> up. So I
>>>>> think it's safest to preserve the historical sec= behavior and
>>>>> give
>>>>> users a way to override the negotiation, to cut down on bug
>>>>> reports of
>>>>> mount failures on upgrade.
>>>>
>>>> OK, if this is a recently introduced server problem, then why do we
>>>> need to adjust client-side behavior? Trond's response in cases
>>>> like
>>>> this is usually "fix the d*mn server," which you've already done.
>>>
>>> What is the definition of "recently introduced" here? What is the
>>> exact
>>> commit that introduced the bug in nfs-utils?
>>
>> By the way, looking at 'gitk utils/mountd/mountd.c' in my tree:
>>
>> Originally (didn't look to see how far it goes back), mountd
>> returned AUTH_NULL, AUTH_UNIX, in that order.
>> 53c5bd65c74, first in 1.0.8, always returns
>> AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I,
>> AUTH_GSS_KRB5P, in that order.
>
> So all these should work without any trouble.
>
>> 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
>> list.
>
> Does the server support auth_null security? I didn't think it did.
>
>> 603017f2c15, first in 1.1.4, derives the psuedoflavor list from
>> the export (and introduces the above bug).
>
> That means the bug is likely to be in Fedora 10 and 11, the latest
> Debian and Ubuntu, as well as SLES 11. Sounds like a long list to
> me...
Not an argument, but an observation: I think these are all currently
maintained, and would thus be easy to fix.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-21 17:50 ` Chuck Lever
(?)
@ 2009-08-22 1:48 ` Wu Fengguang
-1 siblings, 0 replies; 55+ messages in thread
From: Wu Fengguang @ 2009-08-22 1:48 UTC (permalink / raw)
To: Chuck Lever; +Cc: Trond Myklebust, NFS list, LKML
On Sat, Aug 22, 2009 at 01:50:52AM +0800, Chuck Lever wrote:
>
> On Aug 20, 2009, at 10:36 PM, Trond Myklebust wrote:
>
> > On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote:
> >> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote:
> >>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote:
> >>>> Hi,
> >>>>
> >>>> After upgrading NFS client kernel to latest linux-next, NFS mount
> >>>> failed:
> >>>>
> >>>> # mount -t nfs pxe:/cc /cc
> >>>> mount.nfs: access denied by server while mounting pxe:/cc
> >>>>
> >>>> # uname -a
> >>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20
> >>>> 14:46:10 CST 2009 x86_64 GNU/Linux
> >>>>
> >>>> However server log says OK:
> >>>>
> >>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount
> >>>> request from 192.168.11.6:973 for /cc (/cc)
> >>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount
> >>>> request from 192.168.11.6:974 for /cc (/cc)
> >>>>
> >>>> However-2: nfsroot can be mounted at boot time. Server kernel has
> >>>> always been 2.6.30.
> >>>>
> >>>> Any ideas?
> >>>>
> >>>> Thanks,
> >>>> Fengguang
> >>>
> >>> Can you try again after enabling mount debugging on the NFS client?
> >>>
> >>> echo 512 > /proc/sys/sunrpc/nfs_debug
> >>
> >> I used 1024 and found the mount failed here in nfs_walk_authlist():
> >>
> >> dfprintk(MOUNT, "NFS: server does not support requested auth
> >> flavor\ n");
> >> nfs_umount(request);
> >
> > Thanks Fengguang!
> >
> > Chuck, this looks like one of yours. Could it be that you are hitting
> > the same Linux knfsd bug that Tom Haynes saw with a Solaris client?
> > AFAICR, the problem was that existing nfs servers do not set a default
> > auth flavour, and so you just have to try with auth_sys and see if it
> > succeeds...
>
> With 1024 set, the mount client's XDR routines should have listed the
> server's flavors, if any, in the system log. Should be something like
> "NFS: received 0 auth flavors" if the server didn't return any. Can
> you confirm that?
Yes. The full logs are:
Aug 21 09:54:38 hp kernel: [ 74.671552] NFS: nfs mount opts='nolock,addr=192.168.11.2'
Aug 21 09:54:38 hp kernel: [ 74.677150] NFS: parsing nfs mount option 'nolock'
Aug 21 09:54:38 hp kernel: [ 74.682204] NFS: parsing nfs mount option 'addr=192.168.11.2'
Aug 21 09:54:38 hp kernel: [ 74.688234] NFS: MNTPATH: '/cc'
Aug 21 09:54:38 hp kernel: [ 74.691468] NFS: sending MNT request for pxe:/cc
Aug 21 09:54:38 hp kernel: [ 74.704458] NFS: received 0 auth flavors
Aug 21 09:54:38 hp kernel: [ 74.708587] NFS: MNT request succeeded
Aug 21 09:54:38 hp kernel: [ 74.712435] NFS: server does not support requested auth flavor
Aug 21 09:54:38 hp kernel: [ 74.718358] NFS: sending UMNT request for pxe:/cc
> I'll try to post a fix later today.
Thanks!
Fengguang
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Fwd: mount.nfs: access denied by server
2009-08-21 18:20 ` J. Bruce Fields
2009-08-21 20:20 ` Chuck Lever
@ 2009-08-24 12:15 ` Steve Dickson
1 sibling, 0 replies; 55+ messages in thread
From: Steve Dickson @ 2009-08-24 12:15 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Chuck Lever, Trond Myklebust, NFS list, Tom Haynes
On 08/21/2009 02:20 PM, J. Bruce Fields wrote:
> Author: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Tue Jul 21 19:30:04 2009 -0400
>
> Don't give client an empty flavor list
>
> In the absence of an explicit sec= option on an export, rpc.mountd is
> returning a zero-length flavor list to clients in the MOUNT results.
>
> The linux client doesn't seem to mind, but the Solaris client
> (reasonably enough) is giving up; the symptom is a "security mode does
> not match" error on mount.
>
> We could modify the export-parsing code to ensure the secinfo array is
> nonzero. But I think it's slightly simpler to handle this default case
> in the implementation of the MOUNT call. This is more-or-less the same
> thing the kernel does when mountd passes it an export without any
> security flavors specified.
>
> Thanks to Tom Haynes for bug report and diagnosis.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
>
> diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
> index b59f939..888fd8c 100644
> --- a/utils/mountd/mountd.c
> +++ b/utils/mountd/mountd.c
> @@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok *ok, nfs_export *exp)
> flavors[i] = s->flav->fnum;
> i++;
> }
> + if (i == 0) {
> + /* default when there is no sec= option: */
> + i = 1;
> + flavors[0] = AUTH_UNIX;
> + }
> ok->auth_flavors.auth_flavors_val = flavors;
> ok->auth_flavors.auth_flavors_len = i;
> }
Committed....
steved.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1250891463.5700.21.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-24 16:10 ` J. Bruce Fields
2009-08-24 16:22 ` Chuck Lever
2009-08-24 17:06 ` Trond Myklebust
0 siblings, 2 replies; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-24 16:10 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, NFS list, Tom Haynes
On Fri, Aug 21, 2009 at 05:51:02PM -0400, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
> > > On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
> > > > 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> > > > list.
> > >
> > > Does the server support auth_null security? I didn't think it did.
> >
> > Just off the top of my head, without looking at the code: I believe it
> > treats auth_null rpc calls exactly as if they were auth_sys calls with
> > uid and gid set to the "anonymous" uid and gid.
>
> OK, so that would break too.
I've lost track of the antecedent to "that".
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-24 16:10 ` J. Bruce Fields
@ 2009-08-24 16:22 ` Chuck Lever
2009-08-24 17:06 ` Trond Myklebust
1 sibling, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-24 16:22 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Trond Myklebust, NFS list, Tom Haynes
On Aug 24, 2009, at 12:10 PM, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 05:51:02PM -0400, Trond Myklebust wrote:
>> On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
>>> On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
>>>> On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
>>>>> 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
>>>>> list.
>>>>
>>>> Does the server support auth_null security? I didn't think it did.
>>>
>>> Just off the top of my head, without looking at the code: I
>>> believe it
>>> treats auth_null rpc calls exactly as if they were auth_sys calls
>>> with
>>> uid and gid set to the "anonymous" uid and gid.
>>
>> OK, so that would break too.
>
> I've lost track of the antecedent to "that".
I think what is meant here is:
If the NFS server does support AUTH_NULL, (properly working) clients
won't use it unless it is listed in the flavor list passed back by MNT.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-24 16:10 ` J. Bruce Fields
2009-08-24 16:22 ` Chuck Lever
@ 2009-08-24 17:06 ` Trond Myklebust
[not found] ` <1251133618.6325.262.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
1 sibling, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-24 17:06 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Chuck Lever, NFS list, Tom Haynes
On Mon, 2009-08-24 at 12:10 -0400, J. Bruce Fields wrote:
> On Fri, Aug 21, 2009 at 05:51:02PM -0400, Trond Myklebust wrote:
> > On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
> > > On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
> > > > On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
> > > > > 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> > > > > list.
> > > >
> > > > Does the server support auth_null security? I didn't think it did.
> > >
> > > Just off the top of my head, without looking at the code: I believe it
> > > treats auth_null rpc calls exactly as if they were auth_sys calls with
> > > uid and gid set to the "anonymous" uid and gid.
> >
> > OK, so that would break too.
>
> I've lost track of the antecedent to "that".
Negotiating AUTH_NULL security for those mountd programs that fake up a
list of flavours that excludes AUTH_NULL.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1251133618.6325.262.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-24 17:41 ` J. Bruce Fields
2009-08-25 15:36 ` Chuck Lever
0 siblings, 1 reply; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-24 17:41 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Chuck Lever, NFS list, Tom Haynes
On Mon, Aug 24, 2009 at 01:06:58PM -0400, Trond Myklebust wrote:
> On Mon, 2009-08-24 at 12:10 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 21, 2009 at 05:51:02PM -0400, Trond Myklebust wrote:
> > > On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
> > > > On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
> > > > > On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
> > > > > > 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> > > > > > list.
> > > > >
> > > > > Does the server support auth_null security? I didn't think it did.
> > > >
> > > > Just off the top of my head, without looking at the code: I believe it
> > > > treats auth_null rpc calls exactly as if they were auth_sys calls with
> > > > uid and gid set to the "anonymous" uid and gid.
> > >
> > > OK, so that would break too.
> >
> > I've lost track of the antecedent to "that".
>
> Negotiating AUTH_NULL security for those mountd programs that fake up a
> list of flavours that excludes AUTH_NULL.
OK, got it.
(And note (a reminder to anyone that forgot) the omission of AUTH_NULL
is a workaround for a bug in older mount.nfs which caused the client to
prefer flavors at the end of the list. (Fixed in 3c1bb23c03, which went
into 1.1.3. When was that bug introduced?) That means some clients
read the list forwards, and some backwards, so if you want clients to
avoid picking AUTH_NULL by default, there's no safe place to put it.
Since AUTH_NULL seems rarely needed, it seemed best just to leave it
off.)
Anyway, we could add a second special case on the client side that
allowed an explicit sec=null to bypass checking against the server list.
I don't know who actually needs mounts with sec=null.
And/or we could plan to put AUTH_NULL back on the server's list some
day, depending on how widely disseminated we think the backwards mount
behavior was....
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-24 17:41 ` J. Bruce Fields
@ 2009-08-25 15:36 ` Chuck Lever
2009-08-25 16:49 ` Tom Haynes
0 siblings, 1 reply; 55+ messages in thread
From: Chuck Lever @ 2009-08-25 15:36 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Trond Myklebust, NFS list, Tom Haynes
On Aug 24, 2009, at 1:41 PM, J. Bruce Fields wrote:
> On Mon, Aug 24, 2009 at 01:06:58PM -0400, Trond Myklebust wrote:
>> On Mon, 2009-08-24 at 12:10 -0400, J. Bruce Fields wrote:
>>> On Fri, Aug 21, 2009 at 05:51:02PM -0400, Trond Myklebust wrote:
>>>> On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
>>>>> On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
>>>>>> On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
>>>>>>> 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
>>>>>>> list.
>>>>>>
>>>>>> Does the server support auth_null security? I didn't think it
>>>>>> did.
>>>>>
>>>>> Just off the top of my head, without looking at the code: I
>>>>> believe it
>>>>> treats auth_null rpc calls exactly as if they were auth_sys
>>>>> calls with
>>>>> uid and gid set to the "anonymous" uid and gid.
>>>>
>>>> OK, so that would break too.
>>>
>>> I've lost track of the antecedent to "that".
>>
>> Negotiating AUTH_NULL security for those mountd programs that fake
>> up a
>> list of flavours that excludes AUTH_NULL.
>
> OK, got it.
>
> (And note (a reminder to anyone that forgot) the omission of AUTH_NULL
> is a workaround for a bug in older mount.nfs which caused the client
> to
> prefer flavors at the end of the list. (Fixed in 3c1bb23c03, which
> went
> into 1.1.3. When was that bug introduced?) That means some clients
> read the list forwards, and some backwards, so if you want clients to
> avoid picking AUTH_NULL by default, there's no safe place to put it.
> Since AUTH_NULL seems rarely needed, it seemed best just to leave it
> off.)
RFC 2623 suggests how the server should sort the returned flavor
list. However I don't think there's a consistent algorithm the client
can use with that list to determine a good default for that mount.
So, I would argue that any client that uses the "first" or "last"
entry in that list as the mount's auth flavor is probably broken; it
should pick a sec= default for all mounts, and if it's not on the
returned list, fail the mount. That is, incidentally, what the kernel
MNT client does now.
> Anyway, we could add a second special case on the client side that
> allowed an explicit sec=null to bypass checking against the server
> list.
> I don't know who actually needs mounts with sec=null.
Or, we can make sure the server provides AUTH_NULL in the list _only_
if that flavor is specified explicitly on the export line. Otherwise,
a single entry flavor list (ie supporting only AUTH_UNIX) is probably
the best default we can provide for the reasons you state above.
It would help to provide some documenting comments to that effect in
the code, or maybe even state it in the exports(5) man page.
> And/or we could plan to put AUTH_NULL back on the server's list some
> day, depending on how widely disseminated we think the backwards mount
> behavior was....
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-25 15:36 ` Chuck Lever
@ 2009-08-25 16:49 ` Tom Haynes
[not found] ` <4A94162C.20904-xsfywfwIY+M@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Tom Haynes @ 2009-08-25 16:49 UTC (permalink / raw)
To: Chuck Lever; +Cc: J. Bruce Fields, Trond Myklebust, NFS list
Chuck Lever wrote:
>
> RFC 2623 suggests how the server should sort the returned flavor
> list. However I don't think there's a consistent algorithm the client
> can use with that list to determine a good default for that mount.
> So, I would argue that any client that uses the "first" or "last"
> entry in that list as the mount's auth flavor is probably broken; it
> should pick a sec= default for all mounts, and if it's not on the
> returned list, fail the mount. That is, incidentally, what the kernel
> MNT client does now.
>
The MOUNT Version 3 protocol, associated with NFS Version 3, solves
the problem by having the response to the MNT procedure include a
list of flavors in the MNT procedure. Note that because some NFS
servers will export file systems to specific lists of clients, with
different access (read-only versus read-write), and with different
security flavors, it is possible a client might get back multiple
security flavors in the list returned in the MNT response. The use of
one flavor instead of another might imply read-only instead of read-
write access, or perhaps some other degradation of access. For this
reason, a NFS client SHOULD use the first flavor in the list that it
supports, on the assumption that the best access is provided by the
first flavor. NFS servers that support the ability to export file
systems with multiple security flavors SHOULD either present the best
accessing flavor first to the client, or leave the order under the
control of the system administrator.
It sounds pretty clear, the server SHOULD order them in some fashion and
the client SHOULD
pick the first one it supports in the list. It is not 'MUST', but if all
servers and clients follow the same
algorithm, it becomes accepted practice.
Having said that, our nfssec(5) states that a client can pick any of the
modes in the list.
But our server returns them in the order entered in the share by the admin.
The client either:
1) Uses the explicit flavor set in the mount command.
or
2) Uses the first supported one in the list.
or
3) Fails the mount.
With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
support the autonegotiation
as defined in the protocol.
We just went through a regression with this algorithm.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <4A94162C.20904-xsfywfwIY+M@public.gmane.org>
@ 2009-08-25 16:58 ` Trond Myklebust
[not found] ` <1251219492.25372.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-25 17:40 ` Chuck Lever
1 sibling, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-25 16:58 UTC (permalink / raw)
To: Tom Haynes; +Cc: Chuck Lever, J. Bruce Fields, NFS list
On Tue, 2009-08-25 at 11:49 -0500, Tom Haynes wrote:
> With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
> support the autonegotiation
> as defined in the protocol.
>
> We just went through a regression with this algorithm.
NFSv4 also allows the server to change the list of supported security
flavours on the fly at any point in the namespace, and at any time. How
does OpenSolaris currently deal with this?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <4A94162C.20904-xsfywfwIY+M@public.gmane.org>
2009-08-25 16:58 ` Trond Myklebust
@ 2009-08-25 17:40 ` Chuck Lever
2009-08-25 18:02 ` Tom Haynes
2009-08-25 18:10 ` J. Bruce Fields
1 sibling, 2 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-25 17:40 UTC (permalink / raw)
To: Tom Haynes; +Cc: J. Bruce Fields, Trond Myklebust, NFS list
On Aug 25, 2009, at 12:49 PM, Tom Haynes wrote:
> Chuck Lever wrote:
>>
>> RFC 2623 suggests how the server should sort the returned flavor
>> list. However I don't think there's a consistent algorithm the
>> client can use with that list to determine a good default for that
>> mount. So, I would argue that any client that uses the "first" or
>> "last" entry in that list as the mount's auth flavor is probably
>> broken; it should pick a sec= default for all mounts, and if it's
>> not on the returned list, fail the mount. That is, incidentally,
>> what the kernel MNT client does now.
>>
>
> The MOUNT Version 3 protocol, associated with NFS Version 3, solves
> the problem by having the response to the MNT procedure include a
> list of flavors in the MNT procedure. Note that because some NFS
> servers will export file systems to specific lists of clients, with
> different access (read-only versus read-write), and with different
> security flavors, it is possible a client might get back multiple
> security flavors in the list returned in the MNT response. The use of
> one flavor instead of another might imply read-only instead of read-
> write access, or perhaps some other degradation of access. For this
> reason, a NFS client SHOULD use the first flavor in the list that it
> supports, on the assumption that the best access is provided by the
> first flavor. NFS servers that support the ability to export file
> systems with multiple security flavors SHOULD either present the best
> accessing flavor first to the client, or leave the order under the
> control of the system administrator.
>
>
>
> It sounds pretty clear,
Depends on how you define "best access." Besides there's no
indication in the returned list of whether the access granted by the
server will be r/w, r/o, or what.
> the server SHOULD order them in some fashion and the client SHOULD
> pick the first one it supports in the list. It is not 'MUST', but if
> all servers and clients follow the same
> algorithm, it becomes accepted practice.
There was a reason for picking the last one on the list rather than
the first, but I don't remember what it was. Clients ought to behave
consistently across implementations, but we unfortunately have some
behavioral precedents.
> Having said that, our nfssec(5) states that a client can pick any of
> the modes in the list.
>
> But our server returns them in the order entered in the share by the
> admin.
Which seems like it too ignores the 2623 prescription...?
> The client either:
>
> 1) Uses the explicit flavor set in the mount command.
> or
> 2) Uses the first supported one in the list.
> or
> 3) Fails the mount.
>
> With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
> support the autonegotiation
> as defined in the protocol.
>
> We just went through a regression with this algorithm.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-25 17:40 ` Chuck Lever
@ 2009-08-25 18:02 ` Tom Haynes
2009-08-25 18:10 ` J. Bruce Fields
1 sibling, 0 replies; 55+ messages in thread
From: Tom Haynes @ 2009-08-25 18:02 UTC (permalink / raw)
To: Chuck Lever; +Cc: J. Bruce Fields, Trond Myklebust, NFS list
Chuck Lever wrote:
> On Aug 25, 2009, at 12:49 PM, Tom Haynes wrote:
>> Chuck Lever wrote:
>>>
>>> RFC 2623 suggests how the server should sort the returned flavor
>>> list. However I don't think there's a consistent algorithm the
>>> client can use with that list to determine a good default for that
>>> mount. So, I would argue that any client that uses the "first" or
>>> "last" entry in that list as the mount's auth flavor is probably
>>> broken; it should pick a sec= default for all mounts, and if it's
>>> not on the returned list, fail the mount. That is, incidentally,
>>> what the kernel MNT client does now.
>>>
>>
>> The MOUNT Version 3 protocol, associated with NFS Version 3, solves
>> the problem by having the response to the MNT procedure include a
>> list of flavors in the MNT procedure. Note that because some NFS
>> servers will export file systems to specific lists of clients, with
>> different access (read-only versus read-write), and with different
>> security flavors, it is possible a client might get back multiple
>> security flavors in the list returned in the MNT response. The use of
>> one flavor instead of another might imply read-only instead of read-
>> write access, or perhaps some other degradation of access. For this
>> reason, a NFS client SHOULD use the first flavor in the list that it
>> supports, on the assumption that the best access is provided by the
>> first flavor. NFS servers that support the ability to export file
>> systems with multiple security flavors SHOULD either present the best
>> accessing flavor first to the client, or leave the order under the
>> control of the system administrator.
>>
>>
>>
>> It sounds pretty clear,
>
> Depends on how you define "best access." Besides there's no
> indication in the returned list of whether the access granted by the
> server will be r/w, r/o, or what.
>
The quote addresses that - there is no way beforehand to determine
whether the
client wants r/w access, etc. So the server defines the access ordering.
I.e., if
the export is:
/foo sec=krb5,rw,sec=sys,ro
The admin is stating I'll grant you r/w access only if you are secure.
But consider:
/bar sec=krb5,rw,sec=sys,rw=@10.10.20/24,ro
Which states that if you are on the management network, you can get r/w
access
with AUTH_SYS.
In this case, the admin is also stating that they would prefer you use
kerberos, even
if you are on the management network, But they won't penalize you.
And consider:
/open sec=sys:krb5,rw
/somewhat_secure sec=krb5:sys,rw
The second one is designed to have people use kerberos first and the
first allows
people to use kerberos if they have it.
A client can force the issue with:
mount -o sec=krb5 server:/open /mnt
but in the absence of that information, they will most likely get the
first flavor.
The way the spec handles this mess is simple, the server admin knows how
they
want to restrict access to their export/share. So they configure the
export and
the list of flavors goes out in the order they provided.
And the client should *trust* the server and use the first suported one.
If the
user tries:
mount -o server:/foo /mnt
and realizes they do not have r/w permissions, they check the export
access list
and do:
umount /mnt
mound -o sec=krb5 server:/foo /mnt
>> the server SHOULD order them in some fashion and the client SHOULD
>> pick the first one it supports in the list. It is not 'MUST', but if
>> all servers and clients follow the same
>> algorithm, it becomes accepted practice.
>
> There was a reason for picking the last one on the list rather than
> the first, but I don't remember what it was. Clients ought to behave
> consistently across implementations, but we unfortunately have some
> behavioral precedents.
>
>> Having said that, our nfssec(5) states that a client can pick any of
>> the modes in the list.
>>
>> But our server returns them in the order entered in the share by the
>> admin.
>
> Which seems like it too ignores the 2623 prescription...?
Nope, read the last line I quoted.
>
>> The client either:
>>
>> 1) Uses the explicit flavor set in the mount command.
>> or
>> 2) Uses the first supported one in the list.
>> or
>> 3) Fails the mount.
>>
>> With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
>> support the autonegotiation
>> as defined in the protocol.
>>
>> We just went through a regression with this algorithm.
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-25 17:40 ` Chuck Lever
2009-08-25 18:02 ` Tom Haynes
@ 2009-08-25 18:10 ` J. Bruce Fields
2009-08-25 19:05 ` Chuck Lever
1 sibling, 1 reply; 55+ messages in thread
From: J. Bruce Fields @ 2009-08-25 18:10 UTC (permalink / raw)
To: Chuck Lever; +Cc: Tom Haynes, Trond Myklebust, NFS list
On Tue, Aug 25, 2009 at 01:40:44PM -0400, Chuck Lever wrote:
> On Aug 25, 2009, at 12:49 PM, Tom Haynes wrote:
>> The MOUNT Version 3 protocol, associated with NFS Version 3, solves
>> the problem by having the response to the MNT procedure include a
>> list of flavors in the MNT procedure. Note that because some NFS
>> servers will export file systems to specific lists of clients, with
>> different access (read-only versus read-write), and with different
>> security flavors, it is possible a client might get back multiple
>> security flavors in the list returned in the MNT response. The use of
>> one flavor instead of another might imply read-only instead of read-
>> write access, or perhaps some other degradation of access. For this
>> reason, a NFS client SHOULD use the first flavor in the list that it
>> supports, on the assumption that the best access is provided by the
>> first flavor. NFS servers that support the ability to export file
>> systems with multiple security flavors SHOULD either present the best
>> accessing flavor first to the client, or leave the order under the
>> control of the system administrator.
>>
>>
>>
>> It sounds pretty clear,
>
> Depends on how you define "best access." Besides there's no indication
> in the returned list of whether the access granted by the server will be
> r/w, r/o, or what.
For that reason, all servers I know of have decided to leave the "best
access" decision to the server administrator.
>> the server SHOULD order them in some fashion and the client SHOULD
>> pick the first one it supports in the list. It is not 'MUST', but if
>> all servers and clients follow the same
>> algorithm, it becomes accepted practice.
>
> There was a reason for picking the last one on the list rather than the
> first, but I don't remember what it was. Clients ought to behave
> consistently across implementations, but we unfortunately have some
> behavioral precedents.
Yes, and we need some workarounds for those, as previously discussed,
but the above-quoted SHOULD can still be mostly honored.
>> Having said that, our nfssec(5) states that a client can pick any of
>> the modes in the list.
>>
>> But our server returns them in the order entered in the share by the
>> admin.
>
> Which seems like it too ignores the 2623 prescription...?
We declare the ordering a policy issue and leave it to the server
administrator. The linux server does this as well, and the behavior is
documented in the exports(5) man page.
--b.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1251219492.25372.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-25 18:17 ` Tom Haynes
[not found] ` <4A942ACF.4030502-xsfywfwIY+M@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Tom Haynes @ 2009-08-25 18:17 UTC (permalink / raw)
To: Trond Myklebust; +Cc: NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
Trond Myklebust wrote:
> On Tue, 2009-08-25 at 11:49 -0500, Tom Haynes wrote:
>
>> With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
>> support the autonegotiation
>> as defined in the protocol.
>>
>> We just went through a regression with this algorithm.
>>
>
> NFSv4 also allows the server to change the list of supported security
> flavours on the fly at any point in the namespace, and at any time. How
> does OpenSolaris currently deal with this?
>
>
The client gets a WRONGSEC and then initiates auto-negotiation.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <4A942ACF.4030502-xsfywfwIY+M@public.gmane.org>
@ 2009-08-25 18:39 ` Trond Myklebust
[not found] ` <1251225543.25372.22.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-25 18:39 UTC (permalink / raw)
To: Tom Haynes; +Cc: NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
On Tue, 2009-08-25 at 13:17 -0500, Tom Haynes wrote:
> Trond Myklebust wrote:
> > On Tue, 2009-08-25 at 11:49 -0500, Tom Haynes wrote:
> >
> >> With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
> >> support the autonegotiation
> >> as defined in the protocol.
> >>
> >> We just went through a regression with this algorithm.
> >>
> >
> > NFSv4 also allows the server to change the list of supported security
> > flavours on the fly at any point in the namespace, and at any time. How
> > does OpenSolaris currently deal with this?
> >
> >
>
> The client gets a WRONGSEC and then initiates auto-negotiation.
>
Right, but are there any limits to that?
Will it, for instance, allow process 1 to continue using auth_sys, while
process 2 switches to using krb5 on the same file?
Should it recover in the case where the administrator suddenly removes
krb5 from the list, and replaces it with krb5i on all subdirectories
of ../../.. relative to your current working directory?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1251225543.25372.22.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-25 18:43 ` Trond Myklebust
[not found] ` <1251225797.25372.25.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-25 18:43 UTC (permalink / raw)
To: Tom Haynes; +Cc: NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
On Tue, 2009-08-25 at 14:39 -0400, Trond Myklebust wrote:
> On Tue, 2009-08-25 at 13:17 -0500, Tom Haynes wrote:
> > Trond Myklebust wrote:
> > > On Tue, 2009-08-25 at 11:49 -0500, Tom Haynes wrote:
> > >
> > >> With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
> > >> support the autonegotiation
> > >> as defined in the protocol.
> > >>
> > >> We just went through a regression with this algorithm.
> > >>
> > >
> > > NFSv4 also allows the server to change the list of supported security
> > > flavours on the fly at any point in the namespace, and at any time. How
> > > does OpenSolaris currently deal with this?
> > >
> > >
> >
> > The client gets a WRONGSEC and then initiates auto-negotiation.
> >
>
> Right, but are there any limits to that?
>
> Will it, for instance, allow process 1 to continue using auth_sys, while
> process 2 switches to using krb5 on the same file?
>
> Should it recover in the case where the administrator suddenly removes
> krb5 from the list, and replaces it with krb5i on all subdirectories
> of ../../.. relative to your current working directory?
Sorry. Let me be more specific...
Say you have
/foo sec=krb5,rw
and the administrator adds a new rule
/foo/bar sec=krb5i,rw
Will your autonegotiator be able to recover processes that are working
in /foo/bar/... without disturbing those working in /foo/baz/... ?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
2009-08-25 18:10 ` J. Bruce Fields
@ 2009-08-25 19:05 ` Chuck Lever
0 siblings, 0 replies; 55+ messages in thread
From: Chuck Lever @ 2009-08-25 19:05 UTC (permalink / raw)
To: J. Bruce Fields, Trond Myklebust; +Cc: Tom Haynes, NFS list
On Aug 25, 2009, at 2:10 PM, J. Bruce Fields wrote:
> On Tue, Aug 25, 2009 at 01:40:44PM -0400, Chuck Lever wrote:
>> On Aug 25, 2009, at 12:49 PM, Tom Haynes wrote:
>>> The MOUNT Version 3 protocol, associated with NFS Version 3, solves
>>> the problem by having the response to the MNT procedure include a
>>> list of flavors in the MNT procedure. Note that because some NFS
>>> servers will export file systems to specific lists of clients, with
>>> different access (read-only versus read-write), and with different
>>> security flavors, it is possible a client might get back multiple
>>> security flavors in the list returned in the MNT response. The use
>>> of
>>> one flavor instead of another might imply read-only instead of read-
>>> write access, or perhaps some other degradation of access. For this
>>> reason, a NFS client SHOULD use the first flavor in the list that it
>>> supports, on the assumption that the best access is provided by the
>>> first flavor. NFS servers that support the ability to export file
>>> systems with multiple security flavors SHOULD either present the
>>> best
>>> accessing flavor first to the client, or leave the order under the
>>> control of the system administrator.
>>>
>>>
>>>
>>> It sounds pretty clear,
>>
>> Depends on how you define "best access." Besides there's no
>> indication
>> in the returned list of whether the access granted by the server
>> will be
>> r/w, r/o, or what.
>
> For that reason, all servers I know of have decided to leave the "best
> access" decision to the server administrator.
>
>>> the server SHOULD order them in some fashion and the client SHOULD
>>> pick the first one it supports in the list. It is not 'MUST', but if
>>> all servers and clients follow the same
>>> algorithm, it becomes accepted practice.
>>
>> There was a reason for picking the last one on the list rather than
>> the
>> first, but I don't remember what it was. Clients ought to behave
>> consistently across implementations, but we unfortunately have some
>> behavioral precedents.
>
> Yes, and we need some workarounds for those, as previously discussed,
> but the above-quoted SHOULD can still be mostly honored.
I appreciate the use cases Tom posted, but given that our server
sometimes tries to compensate for the "use the last flavor listed"
behavior of some clients, I would like to understand better what our
kernel client needs to do.
Perhaps we should discuss this in person.
>>> Having said that, our nfssec(5) states that a client can pick any of
>>> the modes in the list.
>>>
>>> But our server returns them in the order entered in the share by the
>>> admin.
>>
>> Which seems like it too ignores the 2623 prescription...?
>
> We declare the ordering a policy issue and leave it to the server
> administrator. The linux server does this as well, and the behavior
> is
> documented in the exports(5) man page.
>
> --b.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <1251225797.25372.25.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-25 22:17 ` Tom Haynes
[not found] ` <4A9462E4.5020404-xsfywfwIY+M@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Tom Haynes @ 2009-08-25 22:17 UTC (permalink / raw)
To: Trond Myklebust; +Cc: NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
Trond Myklebust wrote:
> On Tue, 2009-08-25 at 14:39 -0400, Trond Myklebust wrote:
>
>> On Tue, 2009-08-25 at 13:17 -0500, Tom Haynes wrote:
>>
>>> Trond Myklebust wrote:
>>>
>>>> On Tue, 2009-08-25 at 11:49 -0500, Tom Haynes wrote:
>>>>
>>>>
>>>>> With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
>>>>> support the autonegotiation
>>>>> as defined in the protocol.
>>>>>
>>>>> We just went through a regression with this algorithm.
>>>>>
>>>>>
>>>> NFSv4 also allows the server to change the list of supported security
>>>> flavours on the fly at any point in the namespace, and at any time. How
>>>> does OpenSolaris currently deal with this?
>>>>
>>>>
>>>>
>>> The client gets a WRONGSEC and then initiates auto-negotiation.
>>>
>>>
>> Right, but are there any limits to that?
>>
>> Will it, for instance, allow process 1 to continue using auth_sys, while
>> process 2 switches to using krb5 on the same file?
>>
From *reading* the code, I think process 1 is fat, dumb, and happy
until it tries an
action which generates a WRONGSEC. At that point it will have to negotiate.
>> Should it recover in the case where the administrator suddenly removes
>> krb5 from the list, and replaces it with krb5i on all subdirectories
>> of ../../.. relative to your current working directory?
>>
>
> Sorry. Let me be more specific...
>
> Say you have
>
> /foo sec=krb5,rw
>
> and the administrator adds a new rule
>
> /foo/bar sec=krb5i,rw
>
> Will your autonegotiator be able to recover processes that are working
> in /foo/bar/... without disturbing those working in /foo/baz/... ?
>
>
I'll let someone who knows the client give the real response, but
consider two
threads, one in /foo/baz and one in /foo/bar.
The one in /foo/baz will never get a WRONGSEC.
The one in /foo/bar may never get one either - depending on the server
implementation.
i.e., the server has probably put the FSID in the FH. The client is
handing back
what is probably a non-volatile FH and the server has to honor it. And
the server
may have no clue that the FH is under a new mount point.
What happens if the client redrives a LOOKUP of the directory entry? It
should
discover that the FHs no longer match and do some sort of recovery.
> Cheers
> Trond
>
>
Sounds like a great thing to test at the next BAT. :->
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: mount.nfs: access denied by server
[not found] ` <4A9462E4.5020404-xsfywfwIY+M@public.gmane.org>
@ 2009-08-25 23:20 ` Trond Myklebust
[not found] ` <1251242416.5403.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-25 23:20 UTC (permalink / raw)
To: Tom Haynes; +Cc: NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
On Tue, 2009-08-25 at 17:17 -0500, Tom Haynes wrote:
> Trond Myklebust wrote:
> >> Should it recover in the case where the administrator suddenly removes
> >> krb5 from the list, and replaces it with krb5i on all subdirectories
> >> of ../../.. relative to your current working directory?
> >>
> >
> > Sorry. Let me be more specific...
> >
> > Say you have
> >
> > /foo sec=krb5,rw
> >
> > and the administrator adds a new rule
> >
> > /foo/bar sec=krb5i,rw
> >
> > Will your autonegotiator be able to recover processes that are working
> > in /foo/bar/... without disturbing those working in /foo/baz/... ?
> >
> >
>
>
> I'll let someone who knows the client give the real response, but
> consider two
> threads, one in /foo/baz and one in /foo/bar.
>
> The one in /foo/baz will never get a WRONGSEC.
>
> The one in /foo/bar may never get one either - depending on the server
> implementation.
> i.e., the server has probably put the FSID in the FH. The client is
> handing back
> what is probably a non-volatile FH and the server has to honor it. And
> the server
> may have no clue that the FH is under a new mount point.
>
> What happens if the client redrives a LOOKUP of the directory entry? It
> should
> discover that the FHs no longer match and do some sort of recovery.
I was thinking of the case in which /foo/bar is not actually a mount
point. :-)
If we all agree that the server can only remove security flavours when
crossing a mount point, then all is well, however the protocol doesn't
strictly speaking say that has to be the case.
That worries me...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [nfs-discuss] mount.nfs: access denied by server
[not found] ` <1251242416.5403.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-25 23:37 ` Nicolas Williams
[not found] ` <20090825233758.GZ1033-UdXhSnd/wVw@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Nicolas Williams @ 2009-08-25 23:37 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Tom Haynes, NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
On Tue, Aug 25, 2009 at 07:20:16PM -0400, Trond Myklebust wrote:
> I was thinking of the case in which /foo/bar is not actually a mount
> point. :-)
Looking at code we have
nfs4_secinfo_recov() ->
nfs4_secinfo_vnode() ->
nfs4_secinfo_fh_otw() ->
secinfo_update()
And as you can see nfs4_secinfo_vnode() calls nfs4_secinfo_fh_otw() to
get the SECINFO for the affected FH, but, nfs4_secinfo_fh_otw() updates
the mount's server info.
Which means that WRONGSEC -> SECINFO -> updates the entire mount's sec.
I.e., if you have:
- server:/foo w/ sec=krb5
- server:/foo/bar in the _same_ filesystem (i.e., with same fsid) and
sec=krb5i
the client will probably thrash if you mount server:/foo because each
WRONGSEC from accessing server:/foo/baz will cause the client to update
the entire mount, which will lead to WRONGSEC from accessing
server:/foo/bar, which will lead to WRONGSEC from accessing
server:/foo/baz, which ...
> If we all agree that the server can only remove security flavours when
> crossing a mount point, then all is well, however the protocol doesn't
> strictly speaking say that has to be the case.
I agree, that sounds like a very good rule for now.
One could also argue that clients should handle this on a per-directory
basis, not per-mount. But first we'd have to agree that it's a good
idea to have nested "shares" in the same filesystem.
> That worries me...
Me too.
Nico
--
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [nfs-discuss] mount.nfs: access denied by server
[not found] ` <20090825233758.GZ1033-UdXhSnd/wVw@public.gmane.org>
@ 2009-08-26 0:21 ` Trond Myklebust
[not found] ` <1251246105.5403.12.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 55+ messages in thread
From: Trond Myklebust @ 2009-08-26 0:21 UTC (permalink / raw)
To: Nicolas Williams; +Cc: Tom Haynes, NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
On Tue, 2009-08-25 at 18:37 -0500, Nicolas Williams wrote:
> On Tue, Aug 25, 2009 at 07:20:16PM -0400, Trond Myklebust wrote:
> > I was thinking of the case in which /foo/bar is not actually a mount
> > point. :-)
>
> Looking at code we have
>
> nfs4_secinfo_recov() ->
> nfs4_secinfo_vnode() ->
> nfs4_secinfo_fh_otw() ->
> secinfo_update()
>
> And as you can see nfs4_secinfo_vnode() calls nfs4_secinfo_fh_otw() to
> get the SECINFO for the affected FH, but, nfs4_secinfo_fh_otw() updates
> the mount's server info.
Sorry. I didn't mean to force you into detailed explanations of the
code. As a NetApp employee, I'm not sure I'm licensed to even run
OpenSolaris at this point, let alone look at the code. :-)
> Which means that WRONGSEC -> SECINFO -> updates the entire mount's sec.
>
> I.e., if you have:
>
> - server:/foo w/ sec=krb5
> - server:/foo/bar in the _same_ filesystem (i.e., with same fsid) and
> sec=krb5i
>
> the client will probably thrash if you mount server:/foo because each
> WRONGSEC from accessing server:/foo/baz will cause the client to update
> the entire mount, which will lead to WRONGSEC from accessing
> server:/foo/bar, which will lead to WRONGSEC from accessing
> server:/foo/baz, which ...
OK. This is sort of what I expect we will do for Linux too.
> > If we all agree that the server can only remove security flavours when
> > crossing a mount point, then all is well, however the protocol doesn't
> > strictly speaking say that has to be the case.
>
> I agree, that sounds like a very good rule for now.
>
> One could also argue that clients should handle this on a per-directory
> basis, not per-mount. But first we'd have to agree that it's a good
> idea to have nested "shares" in the same filesystem.
The protocol will even allow you to set the secinfo on a per-file basis.
That sounds insane to me, but...
Anyhow, I think our Linux client should go with the 'remove security
flavours only on mountpoints' rule for now, and then we'll see in time
if any users can justify a more fine grained implementation.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [nfs-discuss] mount.nfs: access denied by server
[not found] ` <1251246105.5403.12.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-08-26 21:03 ` Nicolas Williams
0 siblings, 0 replies; 55+ messages in thread
From: Nicolas Williams @ 2009-08-26 21:03 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Tom Haynes, NFS list, nfs-discuss-xZgeD5Kw2fzokhkdeNNY6A
On Tue, Aug 25, 2009 at 08:21:45PM -0400, Trond Myklebust wrote:
> On Tue, 2009-08-25 at 18:37 -0500, Nicolas Williams wrote:
> > Looking at code we have
> > ...
>
> Sorry. I didn't mean to force you into detailed explanations of the
> code. As a NetApp employee, I'm not sure I'm licensed to even run
> OpenSolaris at this point, let alone look at the code. :-)
Well, you don't need a license to look at it (though you might need
permission from your employer, and they may not grant it), and I can't
imagine that my mentioning a few function names could taint you in any
way. Nor would I normally keep from mentioning actual OpenSolaris code
on OpenSolaris discuss lists. If it helps generic protocol discussions
I'm willing to refrain from further discussing code in any one thread
once you ask that I do, but I'd much rather such discussions take place
in the IETF NFSv4 WG mailing list instead then (where I would generally
refrain from posting code).
> > Which means that WRONGSEC -> SECINFO -> updates the entire mount's sec.
>
> OK. This is sort of what I expect we will do for Linux too.
OK.
> The protocol will even allow you to set the secinfo on a per-file basis.
True.
> That sounds insane to me, but...
NFS clients typically allow you to mount individual files, not just
directories.
There's no "MOUNT" operation in the protocol. Mounts have traditionally
been entirely a client-side concept. NFSv4 exposes server-side
hierarchical filesystem mount structures to the clients, but there's
still no MOUNT operation, and clients needn't even have a notion of
"mount" (POSIX clients may have to, but others may not).
Clients could even treat every FH as needing a "mount" (meaning df(1),
mount(1M), nfsstat(1M), etcetera may list every single file and
directory recently accessed as mounts).
OpenSolaris could react to a WRONGSEC by instantiating a mount
dynamically where there really shouldn't be one. It may even have to,
so that sec= settings may be reported to users through existing
interfaces (unless we don't care for that). The same might apply to
Linux. This sort of complexity argues that SECINFO should be
per-filesystem, but see below.
> Anyhow, I think our Linux client should go with the 'remove security
> flavours only on mountpoints' rule for now, and then we'll see in time
> if any users can justify a more fine grained implementation.
BTW, the same considerations apply to sub-shares with other option
differences.
For example (note: I've not tested this):
server% mount /foo
server% share -F nfs -o rw /foo
server% mkdir /foo/bar
server% mkdir /foo/ick
server% share -F nfs -o ro /foo
client% mount server:/foo /foo
client% touch /foo/ick/a
client% touch /foo/bar/a
touch: cannot create /foo/bar/a: Read-only file system
client% touch /foo/ick/b
touch: cannot create /foo/bar/a: Read-only file system
We ought either say that clients MUST cope with hierarchical shares
within a single filesystem, or that hierarchical shares within a
filesystem MUST NOT be allowed. I'm not sure that I'd be ready to say
the latter, while on the other hand the complexity of the former is
certainly a challenge.
Nico
--
^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2009-08-26 21:46 UTC | newest]
Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-20 7:13 mount.nfs: access denied by server Wu Fengguang
2009-08-20 7:19 ` Wu Fengguang
2009-08-20 13:02 ` Trond Myklebust
2009-08-21 1:27 ` Wu Fengguang
2009-08-21 1:27 ` Wu Fengguang
2009-08-21 2:36 ` Trond Myklebust
2009-08-21 17:50 ` Chuck Lever
2009-08-21 17:50 ` Chuck Lever
2009-08-22 1:48 ` Wu Fengguang
2009-08-21 18:16 ` Fwd: " Chuck Lever
2009-08-21 18:20 ` J. Bruce Fields
2009-08-21 20:20 ` Chuck Lever
2009-08-24 12:15 ` Fwd: " Steve Dickson
2009-08-21 18:24 ` J. Bruce Fields
2009-08-21 18:46 ` Chuck Lever
2009-08-21 20:04 ` J. Bruce Fields
2009-08-21 20:18 ` Tom Haynes
[not found] ` <4A8F0118.60705-xsfywfwIY+M@public.gmane.org>
2009-08-21 20:39 ` Peter Staubach
2009-08-21 20:59 ` J. Bruce Fields
2009-08-21 21:08 ` Trond Myklebust
[not found] ` <1250888892.5700.7.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-21 21:21 ` J. Bruce Fields
2009-08-21 20:36 ` Chuck Lever
2009-08-21 21:15 ` Trond Myklebust
[not found] ` <1250889345.5700.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-21 21:21 ` Tom Haynes
[not found] ` <4A8F0FCC.2080709-xsfywfwIY+M@public.gmane.org>
2009-08-21 21:25 ` Trond Myklebust
2009-08-21 21:30 ` J. Bruce Fields
2009-08-21 21:40 ` Trond Myklebust
[not found] ` <1250890836.5700.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-21 21:47 ` J. Bruce Fields
2009-08-21 21:51 ` Trond Myklebust
[not found] ` <1250891463.5700.21.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-24 16:10 ` J. Bruce Fields
2009-08-24 16:22 ` Chuck Lever
2009-08-24 17:06 ` Trond Myklebust
[not found] ` <1251133618.6325.262.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-24 17:41 ` J. Bruce Fields
2009-08-25 15:36 ` Chuck Lever
2009-08-25 16:49 ` Tom Haynes
[not found] ` <4A94162C.20904-xsfywfwIY+M@public.gmane.org>
2009-08-25 16:58 ` Trond Myklebust
[not found] ` <1251219492.25372.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-25 18:17 ` Tom Haynes
[not found] ` <4A942ACF.4030502-xsfywfwIY+M@public.gmane.org>
2009-08-25 18:39 ` Trond Myklebust
[not found] ` <1251225543.25372.22.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-25 18:43 ` Trond Myklebust
[not found] ` <1251225797.25372.25.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-25 22:17 ` Tom Haynes
[not found] ` <4A9462E4.5020404-xsfywfwIY+M@public.gmane.org>
2009-08-25 23:20 ` Trond Myklebust
[not found] ` <1251242416.5403.3.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-25 23:37 ` [nfs-discuss] " Nicolas Williams
[not found] ` <20090825233758.GZ1033-UdXhSnd/wVw@public.gmane.org>
2009-08-26 0:21 ` Trond Myklebust
[not found] ` <1251246105.5403.12.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-26 21:03 ` Nicolas Williams
2009-08-25 17:40 ` Chuck Lever
2009-08-25 18:02 ` Tom Haynes
2009-08-25 18:10 ` J. Bruce Fields
2009-08-25 19:05 ` Chuck Lever
2009-08-21 22:21 ` Chuck Lever
2009-08-21 21:41 ` Chuck Lever
2009-08-21 19:07 ` Thomas Haynes
[not found] ` <760BE185-BE57-42C2-817C-6776B5B66667-xsfywfwIY+M@public.gmane.org>
2009-08-21 19:22 ` Chuck Lever
2009-08-21 19:40 ` Tom Haynes
[not found] ` <4A8EF847.8030500-xsfywfwIY+M@public.gmane.org>
2009-08-21 20:04 ` Chuck Lever
2009-08-21 20:41 ` Peter Staubach
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.