On Sun, Jul 06, 2014 at 04:01:52PM +0200, Gero Treuner wrote: > Hello everybody, > > I join this mailing list because I want to discuss extending systemctl > with a method to escape unit names. Currently systemd and systemctl > deal with escaped unit names but there are many potential name sources > which doesn't have out-of-the-box escaping methods. > > The issue is a Debian bug related to a service unit for a network > device [0]. > > > Current situation > > * systemctl somewhat supports escaping of paths for the unit types > device and mount (in function unit_name_mangle). > > * systemctl prevents broken unit names by escaping invalid characters, > but doesn't escape in a transparent way clear_name->escaped_name > (it isn't supposed to do that, because "ready-to-use" i. e. escaped > unit names are expected) > > * systemd does not provide access to the escaping methods in a > practical way for most environments. Although the escape mechanism is > documented, have systemd integrators implement it by themself has some > disadvantages: > 1. It can't be simply done in shell only. > 2. Lots of independently created escapes potentially lead to errors, > which can cause various effects up to security risks or system > hangs. > > > Proposal > > 1. Extend systemctl unit name interpretation with a syntax to escape in > controlled manner, preferably capable of escaping only parts of a > given name to support compound names with verbatim content (given by > users typing anything they imagine in their GUI). Hi, this is not useful. The *instance* part is escaped, because it refers to file system paths and other things which are not controlled by systemd or by users of systemd. Unit *names* are controlled, so it's much more productive to simply set some rules which limit what is allowed. All units have a free-text Description= field, which can hold whatever the user wants.
> I and possible more in the world are really tired of implementing > nested escapes. This is a good reason to implement a helper in systemctl... > Therefore the approach is to give the number of > characters instead of any end token. This is friendly to programmers > and CPUs, isn't it? ... no, a few extra cycles spent on string processing do not really matter. > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747044 Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
