Hi, I''m looking at implementing bash command autocompletion for xl (at least for Debian to begin with as that''s what I''m familiar with, and then looking at getting it into other distros). One component that needs to be created for this is a function that enumerates all the current running domains by name. Obviously I can''t use `xl list` because that requires escalated privileges. One gross solution would be to make a small setuid wrapper that just reads the domain names out of xenstore, but I think there is a better solution: By setting the process title (ie. what shows up in `ps` output - sshd does this to show the privileged and non-privileged separated processes), we can make each xl daemon show the domain it is running for. Using a title like ''xl: domain for "<dom name>" (<dom id>)'', the completion script can just execute `ps`, and grep/sed/awk/whatever out the domain names for bash. Setting the process title is done by setproctitle() on BSDs, and on Linux it''s implemented by overwriting the process name given at argv[0]. (In practise, it''s done by creating a compat version of setproctitle() if it''s not provided by the system, and then using whatever OS-dependent method one should be using inside of that. openssl, nginx, util-linux, sendmail etc. have existing implementations to base off of.) I don''t think this violates any ''soft'' privilege boundary as existing qemu DMs already show the domain name they are running for in their command lines, visible to normal users with `ps`. It should also be a reasonable solution technically - one nice side effect of this method is that only domains created by xl will be autocompleted; ones from other toolstacks won''t, which makes sense. Thoughts? Does setting process titles in xl daemons seem like the way to go? - Matthew
Matthew Daley writes ("xl command autocompletion: domain
names"):> I''m looking at implementing bash command autocompletion for xl (at
> least for Debian to begin with as that''s what I''m
familiar with, and
> then looking at getting it into other distros). One component that
> needs to be created for this is a function that enumerates all the
> current running domains by name.
>
> Obviously I can''t use `xl list` because that requires escalated
> privileges. One gross solution would be to make a small setuid wrapper
> that just reads the domain names out of xenstore, but I think there is
> a better solution:
But nothing else you can do with xl will work without those escalated
privileges. So I don''t understand why you can''t just punt if
the user
doesn''t have the right privilege.
Ian.
On Tue, Oct 29, 2013 at 4:57 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Matthew Daley writes ("xl command autocompletion: domain names"): >> I''m looking at implementing bash command autocompletion for xl (at >> least for Debian to begin with as that''s what I''m familiar with, and >> then looking at getting it into other distros). One component that >> needs to be created for this is a function that enumerates all the >> current running domains by name. >> >> Obviously I can''t use `xl list` because that requires escalated >> privileges. One gross solution would be to make a small setuid wrapper >> that just reads the domain names out of xenstore, but I think there is >> a better solution: > > But nothing else you can do with xl will work without those escalated > privileges. So I don''t understand why you can''t just punt if the user > doesn''t have the right privilege.The use case I have in mind is the user using sudo, where the bash completion script will run as the unprivileged shell user still. - Matthew> > Ian.
On Tue, 2013-10-29 at 11:29 +1300, Matthew Daley wrote:> On Tue, Oct 29, 2013 at 4:57 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > Matthew Daley writes ("xl command autocompletion: domain names"): > >> I''m looking at implementing bash command autocompletion for xl (at > >> least for Debian to begin with as that''s what I''m familiar with, and > >> then looking at getting it into other distros). One component that > >> needs to be created for this is a function that enumerates all the > >> current running domains by name. > >> > >> Obviously I can''t use `xl list` because that requires escalated > >> privileges. One gross solution would be to make a small setuid wrapper > >> that just reads the domain names out of xenstore, but I think there is > >> a better solution: > > > > But nothing else you can do with xl will work without those escalated > > privileges. So I don''t understand why you can''t just punt if the user > > doesn''t have the right privilege. > > The use case I have in mind is the user using sudo, where the bash > completion script will run as the unprivileged shell user still.Is this not a common problem with completion vs. sudo? How is it normally dealt with? I don''t necessarily object to setting the process title, it feels a bit 1980s/sendmail-ish to me but that might just be me ;-) On the other hand maybe it is a useful thing to do, is it common(ish) practice for daemons to do that sort of thing these days? (The lack of a standardised interface seem to imply not terribly common...) Ian.
Ian Campbell writes ("Re: xl command autocompletion: domain
names"):> On Tue, 2013-10-29 at 11:29 +1300, Matthew Daley wrote:
> > The use case I have in mind is the user using sudo, where the bash
> > completion script will run as the unprivileged shell user still.
>
> Is this not a common problem with completion vs. sudo? How is it
> normally dealt with?
I''m no expert on bash-completion, but I would have expected in this
kind of case to solve it by either (a) saying DDTT or (b) using sudo
in the completion rune too.
Ian.
On Fri, Nov 1, 2013 at 4:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Tue, 2013-10-29 at 11:29 +1300, Matthew Daley wrote: >> On Tue, Oct 29, 2013 at 4:57 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >> > Matthew Daley writes ("xl command autocompletion: domain names"): >> >> I''m looking at implementing bash command autocompletion for xl (at >> >> least for Debian to begin with as that''s what I''m familiar with, and >> >> then looking at getting it into other distros). One component that >> >> needs to be created for this is a function that enumerates all the >> >> current running domains by name. >> >> >> >> Obviously I can''t use `xl list` because that requires escalated >> >> privileges. One gross solution would be to make a small setuid wrapper >> >> that just reads the domain names out of xenstore, but I think there is >> >> a better solution: >> > >> > But nothing else you can do with xl will work without those escalated >> > privileges. So I don''t understand why you can''t just punt if the user >> > doesn''t have the right privilege. >> >> The use case I have in mind is the user using sudo, where the bash >> completion script will run as the unprivileged shell user still. > > Is this not a common problem with completion vs. sudo? How is it > normally dealt with?I guess most autocompletions don''t need to access information with a different privilege level. Domain names don''t seem like they should be privileged information (that is, to a user that can already run `ps` on the toolstack domain), they just de facto are right now.> > I don''t necessarily object to setting the process title, it feels a bit > 1980s/sendmail-ish to me but that might just be me ;-)Can''t say I have 80s UNIX experience ;)> > On the other hand maybe it is a useful thing to do, is it common(ish) > practice for daemons to do that sort of thing these days? (The lack of a > standardised interface seem to imply not terribly common...)I thought that, apart from this immediate bash-completion use case, it might be useful if an administrator ever needs to associate an xl daemon process to the domain it''s running on behalf of (ie. if you wanted to check its resource use, kill it, ...). Admittedly this is (and should be) a rare occurrence. qemu-xen (not sure about traditional) gets its domain name passed in on the command line already (--name), so it''s not such a useful thing there.> > Ian. >
On Fri, Nov 1, 2013 at 4:22 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Ian Campbell writes ("Re: xl command autocompletion: domain names"): >> On Tue, 2013-10-29 at 11:29 +1300, Matthew Daley wrote: >> > The use case I have in mind is the user using sudo, where the bash >> > completion script will run as the unprivileged shell user still. >> >> Is this not a common problem with completion vs. sudo? How is it >> normally dealt with? > > I''m no expert on bash-completion, but I would have expected in this > kind of case to solve it by either (a) saying DDTT or (b) using sudo > in the completion rune too.None of the existing bash-completion scripts (in Debian anyway) use sudo, so I suppose the answer is (a).> > Ian.
On Tue, 2013-11-05 at 21:10 +1300, Matthew Daley wrote:> > On the other hand maybe it is a useful thing to do, is it common(ish) > > practice for daemons to do that sort of thing these days? (The lack of a > > standardised interface seem to imply not terribly common...) > > I thought that, apart from this immediate bash-completion use case, it > might be useful if an administrator ever needs to associate an xl > daemon process to the domain it''s running on behalf of (ie. if you > wanted to check its resource use, kill it, ...). Admittedly this is > (and should be) a rare occurrence.Right, and TBH the current command line is often pretty arbitrary i.e. it can be "xl migrate-receive blargle" which is not all that useful... Ian.
Matthew Daley writes ("Re: xl command autocompletion: domain
names"):> I guess most autocompletions don''t need to access information with
a
> different privilege level. Domain names don''t seem like they
should be
> privileged information (that is, to a user that can already run `ps`
> on the toolstack domain), they just de facto are right now.
Yes.
> On Fri, Nov 1, 2013 at 4:03 AM, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> > I don''t necessarily object to setting the process title, it
feels a bit
> > 1980s/sendmail-ish to me but that might just be me ;-)
Right.
> Can''t say I have 80s UNIX experience ;)
The problem with it from my point of view is that it''s very difficult
to make it reliable. I don''t mind setting the title for the benefit
of admins, but automatically grepping processes out of ps listings is
pretty poor and shouldn''t be done in bash-completion IMO.
Ian.
On Wed, Nov 6, 2013 at 4:37 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Matthew Daley writes ("Re: xl command autocompletion: domain names"): >> I guess most autocompletions don''t need to access information with a >> different privilege level. Domain names don''t seem like they should be >> privileged information (that is, to a user that can already run `ps` >> on the toolstack domain), they just de facto are right now. > > Yes. > >> On Fri, Nov 1, 2013 at 4:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > I don''t necessarily object to setting the process title, it feels a bit >> > 1980s/sendmail-ish to me but that might just be me ;-) > > Right. > >> Can''t say I have 80s UNIX experience ;) > > The problem with it from my point of view is that it''s very difficult > to make it reliable. I don''t mind setting the title for the benefit > of admins, but automatically grepping processes out of ps listings is > pretty poor and shouldn''t be done in bash-completion IMO.A quick grep through the existing bash-completion scripts doesn''t show any uses of ps, so that is in your favour. I guess I''ll can this idea for getting the names for now then. The thing is, a completion script for xl that doesn''t handle domain names seems a little pointless... - Matthew> > Ian.
On Wed, 2013-11-06 at 13:18 +1300, Matthew Daley wrote:> >> On Fri, Nov 1, 2013 at 4:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> > I don''t necessarily object to setting the process title, it feels a bit > >> > 1980s/sendmail-ish to me but that might just be me ;-) > > > > Right. > > > >> Can''t say I have 80s UNIX experience ;) > > > > The problem with it from my point of view is that it''s very difficult > > to make it reliable. I don''t mind setting the title for the benefit > > of admins, but automatically grepping processes out of ps listings is > > pretty poor and shouldn''t be done in bash-completion IMO. > > A quick grep through the existing bash-completion scripts doesn''t show > any uses of ps, so that is in your favour. I guess I''ll can this idea > for getting the names for now then. The thing is, a completion script > for xl that doesn''t handle domain names seems a little pointless...I presume it does handle it if you use "sudo -s" or su and run the commands actually as root? If so then it''s not a total waste. I can''t think of any alternatives. There is the R/O xenstored socket interface which in principal could be opened up to non-privileged users in dom0 and have xl use it when unprivileged. That doesn''t work with dissag though and is probably a fair bit of work in xl. I''d also be a little wary of exposing bugs (since r/o still means you can send messages to the daemon, just that it will reject XS_WRITE/MKDIR etc). libxl probably leaves some per-domain droppings in /var and such, but I don''t think we''d want to expose that. You could autocomplete all the names found in cfg files under /etc/xen/. Obviously that makes sense for xl create but not so much for the others, although maybe it is better than nothing? Skanky though. Ian.
On Wed, Nov 6, 2013 at 11:03 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Wed, 2013-11-06 at 13:18 +1300, Matthew Daley wrote: > >> >> On Fri, Nov 1, 2013 at 4:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> >> > I don''t necessarily object to setting the process title, it feels a bit >> >> > 1980s/sendmail-ish to me but that might just be me ;-) >> > >> > Right. >> > >> >> Can''t say I have 80s UNIX experience ;) >> > >> > The problem with it from my point of view is that it''s very difficult >> > to make it reliable. I don''t mind setting the title for the benefit >> > of admins, but automatically grepping processes out of ps listings is >> > pretty poor and shouldn''t be done in bash-completion IMO. >> >> A quick grep through the existing bash-completion scripts doesn''t show >> any uses of ps, so that is in your favour. I guess I''ll can this idea >> for getting the names for now then. The thing is, a completion script >> for xl that doesn''t handle domain names seems a little pointless... > > I presume it does handle it if you use "sudo -s" or su and run the > commands actually as root? If so then it''s not a total waste.Which "it" are we talking about here? If you mean a xl bash-completion script, well, that''s still vapourware right now :) I wanted to try and figure something out with these domain names first before diving into the script since the script itself should be pretty simple AFAICT. Using sudo -s would still have issues, since the completion still runs as the unprivileged shell user. su''ing as root would work fine, but one isn''t supposed to be sitting in shells as root all day, no?> > I can''t think of any alternatives. There is the R/O xenstored socket > interface which in principal could be opened up to non-privileged users > in dom0 and have xl use it when unprivileged. That doesn''t work with > dissag though and is probably a fair bit of work in xl. > > I''d also be a little wary of exposing bugs (since r/o still means you > can send messages to the daemon, just that it will reject XS_WRITE/MKDIR > etc).Yeah. I wouldn''t want to go changing stuff so drastically for just a small nice-to-have feature. Especially if it involves the risk of exposing interesting bugs to unprivileged users ;)> > libxl probably leaves some per-domain droppings in /var and such, but I > don''t think we''d want to expose that.Right. The only other idea I''ve not mentioned yet would be to explicitly define a file in /var or wherever which enumerated the currently running domains (created by xl), but IMO that''s silly duplication of information which is just asking for trouble wrt. synchronization with reality.> > You could autocomplete all the names found in cfg files under /etc/xen/. > Obviously that makes sense for xl create but not so much for the others, > although maybe it is better than nothing? Skanky though.Well, for xl create it''d just be using normal filename completion for the config file, nothing special needs to (nor should) be done there. Regardless of that, doing completion this way would assume that all the config files live under /etc/xen. - Matthew> > Ian. >
On Thu, 2013-11-07 at 00:14 +1300, Matthew Daley wrote:> On Wed, Nov 6, 2013 at 11:03 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Wed, 2013-11-06 at 13:18 +1300, Matthew Daley wrote: > > > >> >> On Fri, Nov 1, 2013 at 4:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> >> > I don''t necessarily object to setting the process title, it feels a bit > >> >> > 1980s/sendmail-ish to me but that might just be me ;-) > >> > > >> > Right. > >> > > >> >> Can''t say I have 80s UNIX experience ;) > >> > > >> > The problem with it from my point of view is that it''s very difficult > >> > to make it reliable. I don''t mind setting the title for the benefit > >> > of admins, but automatically grepping processes out of ps listings is > >> > pretty poor and shouldn''t be done in bash-completion IMO. > >> > >> A quick grep through the existing bash-completion scripts doesn''t show > >> any uses of ps, so that is in your favour. I guess I''ll can this idea > >> for getting the names for now then. The thing is, a completion script > >> for xl that doesn''t handle domain names seems a little pointless... > > > > I presume it does handle it if you use "sudo -s" or su and run the > > commands actually as root? If so then it''s not a total waste. > > Which "it" are we talking about here?"it" is the (perhaps future) bash completion.> If you mean a xl bash-completion > script, well, that''s still vapourware right now :) I wanted to try and > figure something out with these domain names first before diving into > the script since the script itself should be pretty simple AFAICT. > > Using sudo -s would still have issues, since the completion still runs > as the unprivileged shell user.sudo -s opens a root shell....> su''ing as root would work fine, but > one isn''t supposed to be sitting in shells as root all day, no?True.> > libxl probably leaves some per-domain droppings in /var and such, but I > > don''t think we''d want to expose that. > > Right. The only other idea I''ve not mentioned yet would be to > explicitly define a file in /var or wherever which enumerated the > currently running domains (created by xl), but IMO that''s silly > duplication of information which is just asking for trouble wrt. > synchronization with reality.Agreed. Ian.
On Thu, Nov 7, 2013 at 12:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Thu, 2013-11-07 at 00:14 +1300, Matthew Daley wrote: >> On Wed, Nov 6, 2013 at 11:03 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > On Wed, 2013-11-06 at 13:18 +1300, Matthew Daley wrote: >> > >> >> >> On Fri, Nov 1, 2013 at 4:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> >> >> > I don''t necessarily object to setting the process title, it feels a bit >> >> >> > 1980s/sendmail-ish to me but that might just be me ;-) >> >> > >> >> > Right. >> >> > >> >> >> Can''t say I have 80s UNIX experience ;) >> >> > >> >> > The problem with it from my point of view is that it''s very difficult >> >> > to make it reliable. I don''t mind setting the title for the benefit >> >> > of admins, but automatically grepping processes out of ps listings is >> >> > pretty poor and shouldn''t be done in bash-completion IMO. >> >> >> >> A quick grep through the existing bash-completion scripts doesn''t show >> >> any uses of ps, so that is in your favour. I guess I''ll can this idea >> >> for getting the names for now then. The thing is, a completion script >> >> for xl that doesn''t handle domain names seems a little pointless... >> > >> > I presume it does handle it if you use "sudo -s" or su and run the >> > commands actually as root? If so then it''s not a total waste. >> >> Which "it" are we talking about here? > > "it" is the (perhaps future) bash completion. > >> If you mean a xl bash-completion >> script, well, that''s still vapourware right now :) I wanted to try and >> figure something out with these domain names first before diving into >> the script since the script itself should be pretty simple AFAICT. >> >> Using sudo -s would still have issues, since the completion still runs >> as the unprivileged shell user. > > sudo -s opens a root shell....Oh, I thought you were talking about completing a command line starting with sudo -s (which I guess is pointless wrt. xl). Then yes, using the shell from sudo -s would be fine. - Matthew> >> su''ing as root would work fine, but >> one isn''t supposed to be sitting in shells as root all day, no? > > True. > >> > libxl probably leaves some per-domain droppings in /var and such, but I >> > don''t think we''d want to expose that. >> >> Right. The only other idea I''ve not mentioned yet would be to >> explicitly define a file in /var or wherever which enumerated the >> currently running domains (created by xl), but IMO that''s silly >> duplication of information which is just asking for trouble wrt. >> synchronization with reality. > > Agreed. > > Ian. >
Matthew Daley writes ("Re: xl command autocompletion: domain
names"):> On Thu, Nov 7, 2013 at 12:16 AM, Ian Campbell
<Ian.Campbell@citrix.com> wrote> > sudo -s opens a root shell....
>
> Oh, I thought you were talking about completing a command line
> starting with sudo -s (which I guess is pointless wrt. xl). Then yes,
> using the shell from sudo -s would be fine.
What I meant by "use sodu" was to have the bash-completion script do
"sudo xl list" to obtain the list of completions. You''ll
probably
want to do something like
bash_completion_sudo () {
if [ x"`whoami`" = xroot ]; then "$@"
else ${BASH_COMPLETION_SUDO-sudo} "$@"; fi
}
bash_completion_sudo xl list
Ian.
At 17:13 +0000 on 06 Nov (1383754404), Ian Jackson wrote:> Matthew Daley writes ("Re: xl command autocompletion: domain names"): > > On Thu, Nov 7, 2013 at 12:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote> > sudo -s opens a root shell.... > > > > Oh, I thought you were talking about completing a command line > > starting with sudo -s (which I guess is pointless wrt. xl). Then yes, > > using the shell from sudo -s would be fine. > > What I meant by "use sodu" was to have the bash-completion script do > "sudo xl list" to obtain the list of completions. You''ll probably > want to do something like > > bash_completion_sudo () { > if [ x"`whoami`" = xroot ]; then "$@" > else ${BASH_COMPLETION_SUDO-sudo} "$@"; fi > } > bash_completion_sudo xl listEek! Surely implicit operations like tab-completion shouldn''t do _anything_ that requires sudo. Tim.
On 06/11/13 17:13, Ian Jackson wrote:> bash_completion_sudo () { > if [ x"`whoami`" = xroot ]; then "$@" > else ${BASH_COMPLETION_SUDO-sudo} "$@"; fi > } > bash_completion_sudo xl listIt''s amazing how old constructs make it into new shell scripts for all the wrong reasons. A long time ago, maybe around Unix Edition 7, maybe before, it was common to see [ x$foo = x ] to test for an empty "$foo". Note the lack of quotes. If $foo is indeed empty then this expanded to [ x = x ] (obviously). Without the x''s you would get [ = "" ] which is equally obviously a syntax error. At some stage, decades ago, [ "$foo" = "" ] became possible and the old syntax which had a naked $foo became obsolete. For some reason there has been a resurgence in the belief that you need the x''s _and_ the quotes. You don''t. Ideally you''d eschew the archaic construct altogether. If this particular case, however, you actually want something quite different: if [ $(id -u) -eq 0 ] ... :) jch
John Haxby writes ("Re: [Xen-devel] xl command autocompletion: domain
names"):> On 06/11/13 17:13, Ian Jackson wrote:
> > bash_completion_sudo () {
> > if [ x"`whoami`" = xroot ]; then "$@"
> > else ${BASH_COMPLETION_SUDO-sudo} "$@"; fi
> > }
> > bash_completion_sudo xl list
>
> It''s amazing how old constructs make it into new shell scripts for
all
> the wrong reasons.
...> For some reason there has been a resurgence in the belief that you need
> the x''s _and_ the quotes. You don''t. Ideally
you''d eschew the archaic
> construct altogether.
The x''s are there in case the string looks like an operator for
test(1). Depending on the exact syntax of the expression inside [ ],
it can be ambiguous. In this case it''s OK (I think) but IMO
it''s a
good habit to always include the x whenever passing string data values
to test(1).
> If this particular case, however, you actually want something quite
> different:
>
> if [ $(id -u) -eq 0 ] ...
I guess. I would still write the " ". Otherwise if id fails for some
ridiculous reason, you get a syntax error from test as well.
Ian.
On 08/11/13 15:11, Ian Jackson wrote:> John Haxby writes ("Re: [Xen-devel] xl command autocompletion: domain names"): >> > On 06/11/13 17:13, Ian Jackson wrote: >>> > > bash_completion_sudo () { >>> > > if [ x"`whoami`" = xroot ]; then "$@" >>> > > else ${BASH_COMPLETION_SUDO-sudo} "$@"; fi >>> > > } >>> > > bash_completion_sudo xl list >> > >> > It''s amazing how old constructs make it into new shell scripts for all >> > the wrong reasons. > ... >> > For some reason there has been a resurgence in the belief that you need >> > the x''s _and_ the quotes. You don''t. Ideally you''d eschew the archaic >> > construct altogether. > The x''s are there in case the string looks like an operator for > test(1). Depending on the exact syntax of the expression inside [ ], > it can be ambiguous. In this case it''s OK (I think) but IMO it''s a > good habit to always include the x whenever passing string data values > to test(1). >I hadn''t thought of that ... Except that test doesn''t seem so easily fooled: test -f == root && echo oops if [ -f == root ]; then echo oops; fi if [ -f /etc/passwd ]; then echo phew; fi At least that''s the case for bash; dash doesn''t like it. Still, that''s today''s new Linux/Unix thing so I''m happy! jch
John Haxby writes ("Re: [Xen-devel] xl command autocompletion: domain
names"):> Except that test doesn''t seem so easily fooled:
>
> test -f == root && echo oops
> if [ -f == root ]; then echo oops; fi
> if [ -f /etc/passwd ]; then echo phew; fi
>
> At least that''s the case for bash; dash doesn''t like it.
>
> Still, that''s today''s new Linux/Unix thing so
I''m happy!
What does
test ''('' = '')''
mean ?
bash treats the ( and ) as literals, but it could treat = as the
literal instead. The grammar in the test(1) manpage I have here seems
to permit both parsings.
I''m sure this is written down in a spec somewhere, but it''s
hardly
unambiguous or unsurprising.
Ian.