Re: ffs and utf8
On Sat, Nov 29, 2014 at 09:48:53PM +0100, Dmitrij D. Czarkoff wrote: > That said, the standard provides just enough facilities to make > filesystem-related aspects of Unicode work nicely, particularily in case > of utf-8. Eg. ability to enforce NFD for all operations on file names > could actually make several things more secure by preventing homograph > attacks. How do you 'enforce' NFD? Let the kernel normalize (ie /destructively/ transform) the file names behind user's back, so that a file will be listed with a different name than that with which it was created? That's very nice and secure, indeed. Reject file names that are not in NFD? But if you're into preventing people from using file names they want to use and have used without problems until now, why not just go all the way back to uppercase + the dot? And btw, normalization won't do much about 'homographs': $ echo > ∕еtс∕раsswd $ rm ∕еtс∕раsswd $
Re: panic during boot of 5.7 in de(4) running in Hyper-V
On Tue, Jun 23, 2015 at 09:08:25PM -0600, Theo de Raadt wrote: > -bcopy(sc->tulip_setupdata, sc->tulip_setupbuf, > - sizeof(sc->tulip_setupbuf)); > +bcopy(sc->tulip_setupdata, sc->tulip_setupbuf, TULIP_SETUP); > +sc->tulip_setupbuf = dma_alloc(TULIP_SETUP, PR_WAITOK); > +sc->tulip_setupdata = malloc(TULIP_SETUP, M_DEVBUF, M_WAITOK); > -u_int32_t tulip_setupbuf[192/sizeof(u_int32_t)]; > -u_int32_t tulip_setupdata[192/sizeof(u_int32_t)]; > +#define TULIP_SETUP (192 / sizeof(u_int32_t)) FWIW, change that to: +#define TULIP_SETUP192 > +u_int32_t *tulip_setupbuf; > +u_int32_t *tulip_setupdata;
document the actual meaning of ssh's "command" argument
After reading just the ssh(1) man page and the usage abstract, some poor soul may think that the "command" argument to ssh may be either a simple command or executable path that will be directly passed to execvp(). Even if he doesn't depend on any extra arguments being either used or ignored, he may be bitten by paths with spaces, or by a login shell that is not /bin/sh-like. Better document the whole thing as it stands; a lot of scripts already depend on the current behaviour, so it's not realistic to expect it to ever change. Index: usr.bin/ssh/ssh.1 === RCS file: /cvs/src/usr.bin/ssh/ssh.1,v retrieving revision 1.371 diff -u -r1.371 ssh.1 --- usr.bin/ssh/ssh.1 4 May 2016 12:21:53 - 1.371 +++ usr.bin/ssh/ssh.1 1 Jun 2016 06:59:46 - @@ -64,7 +64,7 @@ .Op Fl W Ar host : Ns Ar port .Op Fl w Ar local_tun Ns Op : Ns Ar remote_tun .Oo Ar user Ns @ Oc Ns Ar hostname -.Op Ar command +.Op Ar command Op Ar args ... .Ek .Sh DESCRIPTION .Nm @@ -88,8 +88,12 @@ .Pp If .Ar command -is specified, -it is executed on the remote host instead of a login shell. +is specified, it is joined by spaces with any extra +.Ar args +into a command string that +will be executed via the +.Fl c +option of the remote user's login shell instead of an interactive session. .Pp The options are as follows: .Pp @@ -966,9 +970,8 @@ host key is not known or has changed. .Pp When the user's identity has been accepted by the server, the server -either executes the given command in a non-interactive session or, -if no command has been specified, logs into the machine and gives -the user a normal shell as an interactive session. +logs into the machine and uses the remote user's login shell to run +an interactive session or the given command. All communication with the remote command or shell will be automatically encrypted. .Pp Index: usr.bin/ssh/ssh.c === RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.440 diff -u -r1.440 ssh.c --- usr.bin/ssh/ssh.c 4 May 2016 14:29:58 - 1.440 +++ usr.bin/ssh/ssh.c 1 Jun 2016 06:59:46 - @@ -190,7 +190,7 @@ " [-F configfile] [-I pkcs11] [-i identity_file] [-L address]\n" " [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]\n" " [-Q query_option] [-R address] [-S ctl_path] [-W host:port]\n" -" [-w local_tun[:remote_tun]] [user@]hostname [command]\n" +" [-w local_tun[:remote_tun]] [user@]hostname [command [args ...]]\n" ); exit(255); }
Re: document the actual meaning of ssh's "command" argument
On Wed, Jun 01, 2016 at 06:53:10PM +0100, Jason McIntyre wrote: > On Wed, Jun 01, 2016 at 10:04:20AM +0300, pizdel...@gmail.com wrote: > > After reading just the ssh(1) man page and the usage abstract, some poor > > soul may think that the "command" argument to ssh may be either a simple > > command or executable path that will be directly passed to execvp(). > > > > Even if he doesn't depend on any extra arguments being either used or > > ignored, he may be bitten by paths with spaces, or by a login shell that > > is not /bin/sh-like. > > > > Better document the whole thing as it stands; a lot of scripts already > > depend on the current behaviour, so it's not realistic to expect > > it to ever change. > > > > i'm inclined to disagree with this diff, for the following reasons: > > - it's adding needless complexity to an already complex usage/synopsis Is it really? If specifiying a remote command with arguments is not supported, then please have to courage to say so. If it's supported, then how is this adding "needless complexity"? > - i think the manuals have to come at it from a level of expectation > from the reader. otherwise we'd tie ourselves in knots before even > starting the document. The problem is that in its current form, the manual page is lying: both paragraphs that I modified clearly suggest that you may somehow bypass the login shell set in /etc/passwd on the remote machine if you specify a "command" argument, which is ridiculous. It's absolutely acceptable for a manual page to be imprecise and incomplete, but it's not acceptable to read like a lie-to-children "thought provoking" essay. > - it's not really sane to imagine someone would want to run something > like finger(1) on a server but be frustrated because the man page makes > it sound like it's not possible to specify arguments. > > - i don;t think it's within ssh(1)'s remit to describe how to quote > commands. I didn't suggest such a diff. > - comparable pages like sh/ksh do not go down this road either. and > please don;t suggest changing "command" to "string"... > > that's not to say i'm not sympathetic, it's just what i think on > balance. > > jmc > > > Index: usr.bin/ssh/ssh.1 > > === > > RCS file: /cvs/src/usr.bin/ssh/ssh.1,v > > retrieving revision 1.371 > > diff -u -r1.371 ssh.1 > > --- usr.bin/ssh/ssh.1 4 May 2016 12:21:53 - 1.371 > > +++ usr.bin/ssh/ssh.1 1 Jun 2016 06:59:46 - > > @@ -64,7 +64,7 @@ > > .Op Fl W Ar host : Ns Ar port > > .Op Fl w Ar local_tun Ns Op : Ns Ar remote_tun > > .Oo Ar user Ns @ Oc Ns Ar hostname > > -.Op Ar command > > +.Op Ar command Op Ar args ... > > .Ek > > .Sh DESCRIPTION > > .Nm > > @@ -88,8 +88,12 @@ > > .Pp > > If > > .Ar command > > -is specified, > > -it is executed on the remote host instead of a login shell. > > +is specified, it is joined by spaces with any extra > > +.Ar args > > +into a command string that > > +will be executed via the > > +.Fl c > > +option of the remote user's login shell instead of an interactive session. > > .Pp > > The options are as follows: > > .Pp > > @@ -966,9 +970,8 @@ > > host key is not known or has changed. > > .Pp > > When the user's identity has been accepted by the server, the server > > -either executes the given command in a non-interactive session or, > > -if no command has been specified, logs into the machine and gives > > -the user a normal shell as an interactive session. > > +logs into the machine and uses the remote user's login shell to run > > +an interactive session or the given command. > > All communication with > > the remote command or shell will be automatically encrypted. > > .Pp > > Index: usr.bin/ssh/ssh.c > > === > > RCS file: /cvs/src/usr.bin/ssh/ssh.c,v > > retrieving revision 1.440 > > diff -u -r1.440 ssh.c > > --- usr.bin/ssh/ssh.c 4 May 2016 14:29:58 - 1.440 > > +++ usr.bin/ssh/ssh.c 1 Jun 2016 06:59:46 - > > @@ -190,7 +190,7 @@ > > " [-F configfile] [-I pkcs11] [-i identity_file] [-L address]\n" > > " [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p > > port]\n" > > " [-Q query_option] [-R address] [-S ctl_path] [-W host:port]\n" > > -" [-w local_tun[:remote_tun]] [user@]hostname [command]\n" > > +" [-w local_tun[:remote_tun]] [user@]hostname [command [args > > ...]]\n" > > ); > > exit(255); > > }
Re: document the actual meaning of ssh's "command" argument
On Thu, Jun 02, 2016 at 08:53:49AM +1000, Darren Tucker wrote: > > i'm inclined to disagree with this diff, for the following reasons: > > - other than the concatenation with spaces, it's not a behaviour of ssh(1) > but of the server at the other end of the connection, which might use sh -c > or might do something completely different depending on the server. The ssh(1) man page is already documenting quite exhaustively the behaviour of the server at the other end; it is assumed that you're connecting to a real ssh server. If that's not the case, there are a lot of things from that man page that do not work (just try ssh -R 0:host:port with a dropbear server). And please notice that's it's not sh -c as in system(3) or popen(3); if you have /foo/bar as your login shell in /etc/passwd, it's /foo/bar -c.
Re: OpenBSD 4.3 running in VirtualBox? Anyone have it working properly?
On Thu, Aug 07, 2008 at 05:43:23AM +0100, Tomas Bodzar wrote: > 4.3 runs fine on many PCs in Qemu as I tested > (Kubuntu,Mandriva,OpenSUSE,Windows).4.4 is Beta,so there may be problems. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jordi Beltran > Creix > Sent: Thursday, August 07, 2008 5:56 AM > To: misc@openbsd.org > Subject: Re: OpenBSD 4.3 running in VirtualBox? Anyone have it working > properly? > > I tried to run a recent i386 4.4 beta on a KVM/QEMU virtual machine under > Ubuntu and there are some problems with the emulated network. > The driver constantly reports timeouts. > > re0: watchdog timeout > As a side effect the connection is very slow. I assume that doesn't happen on > the actual hardware that QEMU is supposed to emulate, but other OSes don't > have the same problem. That's too easy to fix, if recompiling qemu doesn't scare you. Pick this, from the FreeBSD's qemu patches: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu/files/rtl8139-re-patch?rev=1.1
