2012-09-18 13:27:56 +04:00
/***
This file is part of systemd .
Copyright 2010 Lennart Poettering
systemd is free software ; you can redistribute it and / or modify it
under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation ; either version 2.1 of the License , or
( at your option ) any later version .
systemd is distributed in the hope that it will be useful , but
WITHOUT ANY WARRANTY ; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the GNU
Lesser General Public License for more details .
You should have received a copy of the GNU Lesser General Public License
along with systemd ; If not , see < http : //www.gnu.org/licenses/>.
* * */
2015-10-27 05:01:06 +03:00
# include "alloc-util.h"
2015-10-24 23:58:24 +03:00
# include "cgroup-util.h"
# include "formats-util.h"
# include "macro.h"
2012-09-18 13:27:56 +04:00
# include "specifier.h"
2015-10-24 23:58:24 +03:00
# include "string-util.h"
2012-09-18 13:27:56 +04:00
# include "strv.h"
# include "unit-name.h"
# include "unit-printf.h"
2015-10-26 00:32:30 +03:00
# include "unit.h"
# include "user-util.h"
2012-09-18 13:27:56 +04:00
2013-09-17 19:03:46 +04:00
static int specifier_prefix_and_instance ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
Unit * u = userdata ;
2013-09-17 19:03:46 +04:00
2012-09-18 13:27:56 +04:00
assert ( u ) ;
2015-04-30 21:21:00 +03:00
return unit_name_to_prefix_and_instance ( u - > id , ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_prefix ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
Unit * u = userdata ;
2013-09-17 19:03:46 +04:00
2012-09-18 13:27:56 +04:00
assert ( u ) ;
2015-04-30 21:21:00 +03:00
return unit_name_to_prefix ( u - > id , ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_prefix_unescaped ( char specifier , void * data , void * userdata , char * * ret ) {
_cleanup_free_ char * p = NULL ;
2015-04-30 21:21:00 +03:00
Unit * u = userdata ;
int r ;
2012-09-18 13:27:56 +04:00
assert ( u ) ;
2015-04-30 21:21:00 +03:00
r = unit_name_to_prefix ( u - > id , & p ) ;
if ( r < 0 )
return r ;
2012-09-18 13:27:56 +04:00
2015-04-30 21:21:00 +03:00
return unit_name_unescape ( p , ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_instance_unescaped ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
Unit * u = userdata ;
2013-09-17 19:03:46 +04:00
2012-09-18 13:27:56 +04:00
assert ( u ) ;
2015-10-24 23:55:56 +03:00
return unit_name_unescape ( strempty ( u - > instance ) , ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_filename ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
Unit * u = userdata ;
2013-09-17 19:03:46 +04:00
2012-09-18 13:27:56 +04:00
assert ( u ) ;
if ( u - > instance )
2015-04-30 21:21:00 +03:00
return unit_name_path_unescape ( u - > instance , ret ) ;
2013-09-17 19:03:46 +04:00
else
2015-04-30 21:21:00 +03:00
return unit_name_to_path ( u - > id , ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_cgroup ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
Unit * u = userdata ;
2013-09-17 19:03:46 +04:00
char * n ;
2012-09-18 13:27:56 +04:00
assert ( u ) ;
2013-12-16 07:59:31 +04:00
if ( u - > cgroup_path )
n = strdup ( u - > cgroup_path ) ;
else
n = unit_default_cgroup_path ( u ) ;
2013-09-17 19:03:46 +04:00
if ( ! n )
return - ENOMEM ;
* ret = n ;
return 0 ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_cgroup_root ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
Unit * u = userdata ;
2013-09-17 19:03:46 +04:00
char * n ;
2012-09-18 13:27:56 +04:00
2013-06-20 05:45:08 +04:00
assert ( u ) ;
2012-09-18 13:27:56 +04:00
2015-04-30 13:33:54 +03:00
n = strdup ( u - > manager - > cgroup_root ) ;
if ( ! n )
return - ENOMEM ;
2012-09-18 13:27:56 +04:00
2015-04-30 13:33:54 +03:00
* ret = n ;
return 0 ;
}
2013-09-17 19:03:46 +04:00
2015-04-30 13:33:54 +03:00
static int specifier_cgroup_slice ( char specifier , void * data , void * userdata , char * * ret ) {
Unit * u = userdata ;
char * n ;
assert ( u ) ;
if ( UNIT_ISSET ( u - > slice ) ) {
Unit * slice ;
slice = UNIT_DEREF ( u - > slice ) ;
if ( slice - > cgroup_path )
n = strdup ( slice - > cgroup_path ) ;
else
n = unit_default_cgroup_path ( slice ) ;
} else
n = strdup ( u - > manager - > cgroup_root ) ;
2015-10-24 23:55:56 +03:00
if ( ! n )
return - ENOMEM ;
2012-09-18 13:27:56 +04:00
2013-09-17 19:03:46 +04:00
* ret = n ;
return 0 ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_runtime ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
Unit * u = userdata ;
2013-12-16 07:59:31 +04:00
const char * e ;
2013-09-17 19:03:46 +04:00
char * n = NULL ;
2012-09-18 13:27:56 +04:00
assert ( u ) ;
2015-05-11 23:51:49 +03:00
if ( u - > manager - > running_as = = MANAGER_SYSTEM )
2013-12-16 07:59:31 +04:00
e = " /run " ;
else {
2012-09-18 13:27:56 +04:00
e = getenv ( " XDG_RUNTIME_DIR " ) ;
2013-12-16 07:59:31 +04:00
if ( ! e )
2015-03-13 16:08:00 +03:00
return - EOPNOTSUPP ;
2012-09-18 13:27:56 +04:00
}
2013-12-16 07:59:31 +04:00
n = strdup ( e ) ;
if ( ! n )
return - ENOMEM ;
2013-09-17 19:03:46 +04:00
* ret = n ;
return 0 ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
static int specifier_user_name ( char specifier , void * data , void * userdata , char * * ret ) {
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
char * t ;
2013-12-16 07:59:31 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
/* If we are UID 0 (root), this will not result in NSS,
* otherwise it might . This is good , as we want to be able to
* run this in PID 1 , where our user ID is 0 , but where NSS
* lookups are not allowed . */
2012-12-07 09:01:15 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
t = getusername_malloc ( ) ;
if ( ! t )
2013-09-17 19:03:46 +04:00
return - ENOMEM ;
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
* ret = t ;
2013-09-17 19:03:46 +04:00
return 0 ;
2012-09-18 13:27:56 +04:00
}
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
static int specifier_user_id ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
if ( asprintf ( ret , UID_FMT , getuid ( ) ) < 0 )
2013-09-17 19:03:46 +04:00
return - ENOMEM ;
return 0 ;
2012-09-18 13:27:56 +04:00
}
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
static int specifier_user_home ( char specifier , void * data , void * userdata , char * * ret ) {
2013-12-16 07:59:31 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
/* On PID 1 (which runs as root) this will not result in NSS,
* which is good . See above */
2013-12-16 07:59:31 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
return get_home_dir ( ret ) ;
}
2013-12-16 07:59:31 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
static int specifier_user_shell ( char specifier , void * data , void * userdata , char * * ret ) {
2012-09-18 13:27:56 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
/* On PID 1 (which runs as root) this will not result in NSS,
* which is good . See above */
2012-09-18 13:27:56 +04:00
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
return get_shell ( ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
int unit_name_printf ( Unit * u , const char * format , char * * ret ) {
2012-09-18 13:27:56 +04:00
/*
* This will use the passed string as format string and
* replace the following specifiers :
*
* % n : the full id of the unit ( foo @ bar . waldo )
* % N : the id of the unit without the suffix ( foo @ bar )
* % p : the prefix ( foo )
* % i : the instance ( bar )
*/
const Specifier table [ ] = {
{ ' n ' , specifier_string , u - > id } ,
{ ' N ' , specifier_prefix_and_instance , NULL } ,
{ ' p ' , specifier_prefix , NULL } ,
{ ' i ' , specifier_string , u - > instance } ,
{ 0 , NULL , NULL }
} ;
assert ( u ) ;
assert ( format ) ;
2013-09-17 19:03:46 +04:00
assert ( ret ) ;
2012-09-18 13:27:56 +04:00
2013-09-17 19:03:46 +04:00
return specifier_printf ( format , table , u , ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
int unit_full_printf ( Unit * u , const char * format , char * * ret ) {
2012-09-18 13:27:56 +04:00
/* This is similar to unit_name_printf() but also supports
* unescaping . Also , adds a couple of additional codes :
*
2014-05-08 03:28:44 +04:00
* % f the instance if set , otherwise the id
2012-09-18 13:27:56 +04:00
* % c cgroup path of unit
2013-12-16 07:59:31 +04:00
* % r where units in this slice are placed in the cgroup tree
2013-06-20 05:45:08 +04:00
* % R the root of this systemd ' s instance tree
2012-09-18 13:27:56 +04:00
* % t the runtime directory to place sockets in ( e . g . " /run " or $ XDG_RUNTIME_DIR )
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
* % U the UID of the running user
* % u the username of the running user
* % h the homedir of the running user
* % s the shell of the running user
2012-09-18 13:53:47 +04:00
* % m the machine ID of the running system
* % H the host name of the running system
2013-01-28 08:11:31 +04:00
* % b the boot ID of the running system
2013-07-19 10:45:27 +04:00
* % v ` uname - r ` of the running system
2012-09-18 13:27:56 +04:00
*/
const Specifier table [ ] = {
{ ' n ' , specifier_string , u - > id } ,
{ ' N ' , specifier_prefix_and_instance , NULL } ,
{ ' p ' , specifier_prefix , NULL } ,
{ ' P ' , specifier_prefix_unescaped , NULL } ,
{ ' i ' , specifier_string , u - > instance } ,
{ ' I ' , specifier_instance_unescaped , NULL } ,
{ ' f ' , specifier_filename , NULL } ,
{ ' c ' , specifier_cgroup , NULL } ,
2015-04-30 13:33:54 +03:00
{ ' r ' , specifier_cgroup_slice , NULL } ,
2012-09-18 13:27:56 +04:00
{ ' R ' , specifier_cgroup_root , NULL } ,
{ ' t ' , specifier_runtime , NULL } ,
core: simplify handling of %u, %U, %s and %h unit file specifiers
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
2015-11-01 00:12:51 +03:00
{ ' U ' , specifier_user_id , NULL } ,
2012-09-18 13:27:56 +04:00
{ ' u ' , specifier_user_name , NULL } ,
{ ' h ' , specifier_user_home , NULL } ,
{ ' s ' , specifier_user_shell , NULL } ,
2012-09-18 13:53:47 +04:00
{ ' m ' , specifier_machine_id , NULL } ,
{ ' H ' , specifier_host_name , NULL } ,
{ ' b ' , specifier_boot_id , NULL } ,
2013-07-19 10:45:27 +04:00
{ ' v ' , specifier_kernel_release , NULL } ,
{ }
2012-09-18 13:27:56 +04:00
} ;
2013-09-17 19:03:46 +04:00
assert ( u ) ;
2012-09-18 13:27:56 +04:00
assert ( format ) ;
2013-09-17 19:03:46 +04:00
assert ( ret ) ;
2012-09-18 13:27:56 +04:00
2013-09-17 19:03:46 +04:00
return specifier_printf ( format , table , u , ret ) ;
2012-09-18 13:27:56 +04:00
}
2013-09-17 19:03:46 +04:00
int unit_full_printf_strv ( Unit * u , char * * l , char * * * ret ) {
2012-09-18 13:27:56 +04:00
size_t n ;
char * * r , * * i , * * j ;
2013-09-17 19:03:46 +04:00
int q ;
2012-09-18 13:27:56 +04:00
/* Applies unit_full_printf to every entry in l */
assert ( u ) ;
n = strv_length ( l ) ;
r = new ( char * , n + 1 ) ;
if ( ! r )
2013-09-17 19:03:46 +04:00
return - ENOMEM ;
2012-09-18 13:27:56 +04:00
for ( i = l , j = r ; * i ; i + + , j + + ) {
2013-09-17 19:03:46 +04:00
q = unit_full_printf ( u , * i , j ) ;
if ( q < 0 )
2012-09-18 13:27:56 +04:00
goto fail ;
}
* j = NULL ;
2013-09-17 19:03:46 +04:00
* ret = r ;
return 0 ;
2012-09-18 13:27:56 +04:00
fail :
for ( j - - ; j > = r ; j - - )
free ( * j ) ;
free ( r ) ;
2013-09-17 19:03:46 +04:00
return q ;
2012-09-18 13:27:56 +04:00
}