2019-05-19 20:08:55 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* linux/init/version.c
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 1992 Theodore Ts'o
|
|
|
|
|
*
|
|
|
|
|
* May be freely distributed as part of Linux.
|
|
|
|
|
*/
|
|
|
|
|
|
2009-10-18 06:36:47 +08:00
|
|
|
#include <generated/compile.h>
|
2018-07-06 08:49:37 +08:00
|
|
|
#include <linux/build-salt.h>
|
2021-04-02 07:27:23 +08:00
|
|
|
#include <linux/elfnote-lto.h>
|
2017-11-18 07:29:10 +08:00
|
|
|
#include <linux/export.h>
|
init: add "hostname" kernel parameter
The gethostname system call returns the hostname for the current machine.
However, the kernel has no mechanism to initially set the current
machine's name in such a way as to guarantee that the first userspace
process to call gethostname will receive a meaningful result. It relies
on some unspecified userspace process to first call sethostname before
gethostname can produce a meaningful name.
Traditionally the machine's hostname is set from userspace by the init
system. The init system, in turn, often relies on a configuration file
(say, /etc/hostname) to provide the value that it will supply in the call
to sethostname. Consequently, the file system containing /etc/hostname
usually must be available before the hostname will be set. There may,
however, be earlier userspace processes that could call gethostname before
the file system containing /etc/hostname is mounted. Such a process will
get some other, likely meaningless, name from gethostname (such as
"(none)", "localhost", or "darkstar").
A real-world example where this can happen, and lead to undesirable
results, is with mdadm. When assembling arrays, mdadm distinguishes
between "local" arrays and "foreign" arrays. A local array is one that
properly belongs to the current machine, and a foreign array is one that
is (possibly temporarily) attached to the current machine, but properly
belongs to some other machine. To determine if an array is local or
foreign, mdadm may compare the "homehost" recorded on the array with the
current hostname. If mdadm is run before the root file system is mounted,
perhaps because the root file system itself resides on an md-raid array,
then /etc/hostname isn't yet available and the init system will not yet
have called sethostname, causing mdadm to incorrectly conclude that all of
the local arrays are foreign.
Solving this problem *could* be delegated to the init system. It could be
left up to the init system (including any init system that starts within
an initramfs, if one is in use) to ensure that sethostname is called
before any other userspace process could possibly call gethostname.
However, it may not always be obvious which processes could call
gethostname (for example, udev itself might not call gethostname, but it
could via udev rules invoke processes that do). Additionally, the init
system has to ensure that the hostname configuration value is stored in
some place where it will be readily accessible during early boot.
Unfortunately, every init system will attempt to (or has already attempted
to) solve this problem in a different, possibly incorrect, way. This
makes getting consistently working configurations harder for users.
I believe it is better for the kernel to provide the means by which the
hostname may be set early, rather than making this a problem for the init
system to solve. The option to set the hostname during early startup, via
a kernel parameter, provides a simple, reliable way to solve this problem.
It also could make system configuration easier for some embedded systems.
[dmoulding@me.com: v2]
Link: https://lkml.kernel.org/r/20220506060310.7495-2-dmoulding@me.com
Link: https://lkml.kernel.org/r/20220505180651.22849-2-dmoulding@me.com
Signed-off-by: Dan Moulding <dmoulding@me.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-18 08:31:37 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/printk.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/uts.h>
|
|
|
|
|
#include <linux/utsname.h>
|
2009-10-18 06:52:28 +08:00
|
|
|
#include <generated/utsrelease.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/version.h>
|
2013-04-12 08:50:06 +08:00
|
|
|
#include <linux/proc_ns.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-10-02 17:18:14 +08:00
|
|
|
struct uts_namespace init_uts_ns = {
|
2020-08-03 18:16:21 +08:00
|
|
|
.ns.count = REFCOUNT_INIT(2),
|
2006-10-02 17:18:14 +08:00
|
|
|
.name = {
|
|
|
|
|
.sysname = UTS_SYSNAME,
|
|
|
|
|
.nodename = UTS_NODENAME,
|
|
|
|
|
.release = UTS_RELEASE,
|
|
|
|
|
.version = UTS_VERSION,
|
|
|
|
|
.machine = UTS_MACHINE,
|
|
|
|
|
.domainname = UTS_DOMAINNAME,
|
|
|
|
|
},
|
userns: add a user_namespace as creator/owner of uts_namespace
The expected course of development for user namespaces targeted
capabilities is laid out at https://wiki.ubuntu.com/UserNamespace.
Goals:
- Make it safe for an unprivileged user to unshare namespaces. They
will be privileged with respect to the new namespace, but this should
only include resources which the unprivileged user already owns.
- Provide separate limits and accounting for userids in different
namespaces.
Status:
Currently (as of 2.6.38) you can clone with the CLONE_NEWUSER flag to
get a new user namespace if you have the CAP_SYS_ADMIN, CAP_SETUID, and
CAP_SETGID capabilities. What this gets you is a whole new set of
userids, meaning that user 500 will have a different 'struct user' in
your namespace than in other namespaces. So any accounting information
stored in struct user will be unique to your namespace.
However, throughout the kernel there are checks which
- simply check for a capability. Since root in a child namespace
has all capabilities, this means that a child namespace is not
constrained.
- simply compare uid1 == uid2. Since these are the integer uids,
uid 500 in namespace 1 will be said to be equal to uid 500 in
namespace 2.
As a result, the lxc implementation at lxc.sf.net does not use user
namespaces. This is actually helpful because it leaves us free to
develop user namespaces in such a way that, for some time, user
namespaces may be unuseful.
Bugs aside, this patchset is supposed to not at all affect systems which
are not actively using user namespaces, and only restrict what tasks in
child user namespace can do. They begin to limit privilege to a user
namespace, so that root in a container cannot kill or ptrace tasks in the
parent user namespace, and can only get world access rights to files.
Since all files currently belong to the initila user namespace, that means
that child user namespaces can only get world access rights to *all*
files. While this temporarily makes user namespaces bad for system
containers, it starts to get useful for some sandboxing.
I've run the 'runltplite.sh' with and without this patchset and found no
difference.
This patch:
copy_process() handles CLONE_NEWUSER before the rest of the namespaces.
So in the case of clone(CLONE_NEWUSER|CLONE_NEWUTS) the new uts namespace
will have the new user namespace as its owner. That is what we want,
since we want root in that new userns to be able to have privilege over
it.
Changelog:
Feb 15: don't set uts_ns->user_ns if we didn't create
a new uts_ns.
Feb 23: Move extern init_user_ns declaration from
init/version.c to utsname.h.
Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Daniel Lezcano <daniel.lezcano@free.fr>
Acked-by: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-24 07:43:16 +08:00
|
|
|
.user_ns = &init_user_ns,
|
2014-11-01 10:56:04 +08:00
|
|
|
.ns.inum = PROC_UTS_INIT_INO,
|
2014-11-01 14:32:53 +08:00
|
|
|
#ifdef CONFIG_UTS_NS
|
|
|
|
|
.ns.ops = &utsns_operations,
|
|
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
2006-10-02 17:18:14 +08:00
|
|
|
EXPORT_SYMBOL_GPL(init_uts_ns);
|
2007-01-10 21:45:28 +08:00
|
|
|
|
init: add "hostname" kernel parameter
The gethostname system call returns the hostname for the current machine.
However, the kernel has no mechanism to initially set the current
machine's name in such a way as to guarantee that the first userspace
process to call gethostname will receive a meaningful result. It relies
on some unspecified userspace process to first call sethostname before
gethostname can produce a meaningful name.
Traditionally the machine's hostname is set from userspace by the init
system. The init system, in turn, often relies on a configuration file
(say, /etc/hostname) to provide the value that it will supply in the call
to sethostname. Consequently, the file system containing /etc/hostname
usually must be available before the hostname will be set. There may,
however, be earlier userspace processes that could call gethostname before
the file system containing /etc/hostname is mounted. Such a process will
get some other, likely meaningless, name from gethostname (such as
"(none)", "localhost", or "darkstar").
A real-world example where this can happen, and lead to undesirable
results, is with mdadm. When assembling arrays, mdadm distinguishes
between "local" arrays and "foreign" arrays. A local array is one that
properly belongs to the current machine, and a foreign array is one that
is (possibly temporarily) attached to the current machine, but properly
belongs to some other machine. To determine if an array is local or
foreign, mdadm may compare the "homehost" recorded on the array with the
current hostname. If mdadm is run before the root file system is mounted,
perhaps because the root file system itself resides on an md-raid array,
then /etc/hostname isn't yet available and the init system will not yet
have called sethostname, causing mdadm to incorrectly conclude that all of
the local arrays are foreign.
Solving this problem *could* be delegated to the init system. It could be
left up to the init system (including any init system that starts within
an initramfs, if one is in use) to ensure that sethostname is called
before any other userspace process could possibly call gethostname.
However, it may not always be obvious which processes could call
gethostname (for example, udev itself might not call gethostname, but it
could via udev rules invoke processes that do). Additionally, the init
system has to ensure that the hostname configuration value is stored in
some place where it will be readily accessible during early boot.
Unfortunately, every init system will attempt to (or has already attempted
to) solve this problem in a different, possibly incorrect, way. This
makes getting consistently working configurations harder for users.
I believe it is better for the kernel to provide the means by which the
hostname may be set early, rather than making this a problem for the init
system to solve. The option to set the hostname during early startup, via
a kernel parameter, provides a simple, reliable way to solve this problem.
It also could make system configuration easier for some embedded systems.
[dmoulding@me.com: v2]
Link: https://lkml.kernel.org/r/20220506060310.7495-2-dmoulding@me.com
Link: https://lkml.kernel.org/r/20220505180651.22849-2-dmoulding@me.com
Signed-off-by: Dan Moulding <dmoulding@me.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-07-18 08:31:37 +08:00
|
|
|
static int __init early_hostname(char *arg)
|
|
|
|
|
{
|
|
|
|
|
size_t bufsize = sizeof(init_uts_ns.name.nodename);
|
|
|
|
|
size_t maxlen = bufsize - 1;
|
|
|
|
|
size_t arglen;
|
|
|
|
|
|
|
|
|
|
arglen = strlcpy(init_uts_ns.name.nodename, arg, bufsize);
|
|
|
|
|
if (arglen > maxlen) {
|
|
|
|
|
pr_warn("hostname parameter exceeds %zd characters and will be truncated",
|
|
|
|
|
maxlen);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
early_param("hostname", early_hostname);
|
|
|
|
|
|
2007-01-12 10:18:04 +08:00
|
|
|
/* FIXED STRINGS! Don't touch! */
|
|
|
|
|
const char linux_banner[] =
|
2007-01-10 21:45:28 +08:00
|
|
|
"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
|
|
|
|
|
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
|
|
|
|
|
|
|
|
|
|
const char linux_proc_banner[] =
|
|
|
|
|
"%s version %s"
|
|
|
|
|
" (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
|
|
|
|
|
" (" LINUX_COMPILER ") %s\n";
|
2018-07-06 08:49:37 +08:00
|
|
|
|
|
|
|
|
BUILD_SALT;
|
2021-04-02 07:27:23 +08:00
|
|
|
BUILD_LTO_INFO;
|
