pledge in /bin/mv
Is ok?
Index: mv.c
===
RCS file: /cvs/src/bin/mv/mv.c,v
retrieving revision 1.43
diff -u -p -r1.43 mv.c
--- mv.c17 Nov 2015 18:34:00 - 1.43
+++ mv.c9 Apr 2016 15:44:59 -
@@ -72,6 +72,9 @@ main(int argc, char *argv[])
struct stat sb;
int ch;
char path[PATH_MAX];
+
+ if (pledge("stdio rpath wpath cpath", NULL) == -1)
+ err(1, "pledge");
while ((ch = getopt(argc, argv, "if")) != -1)
switch (ch) {
--- HLG
pledge in /usr.bin/arch
Index: arch.c
===
RCS file: /cvs/src/usr.bin/arch/arch.c,v
retrieving revision 1.17
diff -u -p -r1.17 arch.c
--- arch.c 7 Dec 2015 18:11:37 - 1.17
+++ arch.c 9 Apr 2016 15:04:14 -
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
static void __dead usage(void);
@@ -40,6 +41,9 @@ main(int argc, char *argv[])
extern char *__progname;
int short_form = 0, c;
char *arch, *opts;
+
+ if (pledge("stdio", NULL) == -1)
+ err(1, "pledge");
machine = strcmp(__progname, "machine") == 0;
if (machine) {
--- HLG
Re: [patch] ftpd: ptr == NULL
Seems ok
> -Original Message-
> From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf
> Of frit...@alokat.org
> Sent: Tuesday, April 05, 2016 15:22
> To: tech@openbsd.org
> Subject: [patch] ftpd: ptr == NULL
>
> Hi,
>
> cmd is a ptr.
>
> --f.
>
>
> Index: ftpd.c
> =
> ==
> RCS file: /cvs/src/libexec/ftpd/ftpd.c,v retrieving revision 1.213
> diff -u -r1.213
> ftpd.c
> --- ftpd.c16 Mar 2016 15:41:10 - 1.213
> +++ ftpd.c5 Apr 2016 18:12:20 -
> @@ -1151,7 +1151,7 @@
> pid_t pid;
> time_t start;
>
> - if (cmd == 0) {
> + if (cmd == NULL) {
> fin = fopen(name, "r");
> st.st_size = 0;
> } else {
> @@ -1166,14 +1166,14 @@
> if (fin == NULL) {
> if (errno != 0) {
> perror_reply(550, name);
> - if (cmd == 0) {
> + if (cmd == NULL) {
> LOGCMD("get", name);
> }
> }
> return;
> }
> byte_count = -1;
> - if (cmd == 0 && (fstat(fileno(fin), ) < 0 || !S_ISREG(st.st_mode))) {
> + if (cmd == NULL && (fstat(fileno(fin), ) < 0 ||
> +!S_ISREG(st.st_mode))) {
> reply(550, "%s: not a plain file.", name);
> goto done;
> }
> @@ -1205,8 +1205,8 @@
> goto done;
> time();
> send_data(fin, dout, (off_t)st.st_blksize, st.st_size,
> - (restart_point == 0 && cmd == 0 && S_ISREG(st.st_mode)));
> - if ((cmd == 0) && stats)
> + (restart_point == 0 && cmd == NULL && S_ISREG(st.st_mode)));
> + if ((cmd == NULL) && stats)
> logxfer(name, byte_count, start);
> (void) fclose(dout);
> data = -1;
> @@ -1214,7 +1214,7 @@
> if (pdata >= 0)
> (void) close(pdata);
> pdata = -1;
> - if (cmd == 0) {
> + if (cmd == NULL) {
> LOGBYTES("get", name, byte_count);
> fclose(fin);
> } else {
smime.p7s
Description: S/MIME cryptographic signature
OpenSSL: replace perror and exit in pledge
Greetings,
Probably wasting some bandwith.
This diff consists of replacing in openssl
if (single_execution) {
if (pledge("args", NULL) == -1) {
perror("pledge");
exit(1);
}
}
if (single_execution)
if (pledge("args", NULL) == -1)
err(1, "pledge");
--- HLG
pledge_err.diff
Description: pledge_err.diff
Re: Minor style rewrite for crypt.c
Index: crypt.c
===
RCS file: /cvs/src/lib/libc/crypt/crypt.c,v
retrieving revision 1.31
diff -u -p -r1.31 crypt.c
--- crypt.c 12 Sep 2015 14:56:50 - 1.31
+++ crypt.c 4 Apr 2016 02:57:09 -
@@ -7,15 +7,10 @@
char *
crypt(const char *key, const char *setting)
{
- if (setting[0] == '$') {
- switch (setting[1]) {
- case '2':
- return bcrypt(key, setting);
- default:
- errno = EINVAL;
- return (NULL);
- }
+ if (setting[0] == '$' && setting[1] == '2') {
+ return bcrypt(key, setting);
}
+
errno = EINVAL;
return (NULL);
}
> -Original Message-
> From: Michael McConville [mailto:mm...@mykolab.com]
> Sent: Sunday, April 03, 2016 23:54
> To: Héctor Luis Gimbatti <h...@etale.com.ar>
> Subject: Re: Minor style rewrite for crypt.c
>
> You'll need to check out the CVS repo and send a diff for things like this.
>
> Héctor Luis Gimbatti wrote:
> > Greetings,
> > The function crypt (/usr/src/lib/libc/crypt/crypt.c) might be rewritten as:
> >
> > char *
> > crypt(const char *key, const char *setting) {
> > if (setting[0] == '$' && setting[1] == '2')
> > return bcrypt(key, setting);
> > errno = EINVAL;
> > return (NULL);
> >
> > }
> >
> >
> > --- HLG
> >
[pledge] : Add pledge to sail (game)
Index: main.c
===
RCS file: /cvs/src/games/sail/main.c,v
retrieving revision 1.11
diff -u -p -r1.11 main.c
--- main.c 8 Jan 2016 20:26:33 - 1.11
+++ main.c 4 Apr 2016 01:19:59 -
@@ -45,6 +45,9 @@ main(int argc, char **argv)
char *p;
int i;
int fd;
+
+ if (pledge("proc id stdio rpath wpath cpath tty", NULL) == -1)
+ err(1, "pledge");
gid = getgid();
egid = getegid();
--- HLG
Re: bug in grep
Hi,
Apparently the error seems to be in /usr/src/usr.bin/grep/util.c at line 400:
if ((!(lflag || cflag)) && ((!(bol || eol)) &&
((lastHalfDot) && ((firstHalfDot < 0) ||
((fg->patternLen - (lastHalfDot + 1)) < firstHalfDot) {
fg->reversedSearch = 1;
hasDot = fg->patternLen - (firstHalfDot < 0 ?
firstLastHalfDot : firstHalfDot) - 1;
grep_revstr(fg->pattern, fg->patternLen);
}
If you comment out those lines grep works as expected.
$ pwd
/usr/src/usr.bin/grep
$ echo "stuffb01b02stuff" | ./grep -o b..
b01
b02
Cheers
Minor style rewrite for crypt.c
Greetings,
The function crypt (/usr/src/lib/libc/crypt/crypt.c) might be rewritten as:
char *
crypt(const char *key, const char *setting)
{
if (setting[0] == '$' && setting[1] == '2')
return bcrypt(key, setting);
errno = EINVAL;
return (NULL);
}
--- HLG
Re: ifconfig segmentation fault
/etc/hostname.if Inet 1.2.3.4 255.255.255.0 NONE -inet6 # ksh /etc/netstart # ifconfig ## NO PROBLEM /etc/hostname.if Inet 1.2.3.4 255.255.255.0 -inet6 # ksh /etc/netstart ifconfig: -inet6: bad value ## NO SEGMENTATION FAULT So, IMHO, if there is any problem at all, of course it should be due to the ''correctness'' of the line in /etc/hostname. We should check if the parsing of such file is OK (by that I mean of course to check for the correctness of the values ) But AFAIK , and As Far I've tested /etc/hostname.if for different, WRONG LINES, it has never cause ifconfig to segfault.
Re: vfs references to strncpy and MFSNAMELEN
I did not get any reply except yours.-
Indeed patching is very easy that's why I didn't bother to post one and let
most advanced users to patch it.-
Testing for regressions can be hard.-
I've found, in 5.4 version, upto 1400 references to strncpy but most of them
should cause no problem (nor overflow possible if they function which calls it
has the correct 'bounds').
As you correctly said I've missed that reference that expect a nul-terminating
string, however, if the change strncpy/strlcpy is done there should be no
problem to produce a nul-terminate string for the function you mention.
Best regards
-Original Message-
From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of
patrick keshishian
Sent: viernes, 02 de mayo de 2014 00:17
To: tech@openbsd.org; Héctor Luis Gimbatti
Subject: Re: vfs references to strncpy and MFSNAMELEN
On 4/29/14, Héctor Luis Gimbatti h...@etale.com.ar wrote:
The constant MFSNAMELEN as defined in:
lib/libc/sys/getfsstat.2:#define MFSNAMELEN 16
lib/libc/sys/statfs.2:#define MFSNAMELEN 16
sys/sys/mount.h: #define MFSNAMELEN 16
defines the fs type name and, according to comments, it includes nul
terminating character.
The following code makes uses of strncpy and involves MFSNAMELEN
./sys/kern/vfs_subr.c:225: strncpy(mp-mnt_stat.f_fstypename,
vfsp-vfc_name, MFSNAMELEN);
./sys/kern/vfs_subr.c:2272: strncpy(sbp-f_fstypename,
mp-mnt_vfc-vfc_name, MFSNAMELEN);
./sys/kern/vfs_syscalls.c:243: strncpy(mp-mnt_stat.f_fstypename,
vfsp-vfc_name, MFSNAMELEN);
./sys/miscfs/procfs/procfs_vfsops.c:190:strncpy(sbp-f_fstypename,
mp-mnt_vfc-vfc_name, MFSNAMELEN);
./sys/msdosfs/msdosfs_vfsops.c:669: strncpy(sbp-f_fstypename,
mp-mnt_vfc-vfc_name, MFSNAMELEN);
./sys/nfs/nfs_vfsops.c:646: strncpy(mp-mnt_stat.f_fstypename[0],
mp-mnt_vfc-vfc_name, MFSNAMELEN);
./sys/ntfs/ntfs_vfsops.c:628: strncpy(sbp-f_fstypename,
mp-mnt_vfc-vfc_name, MFSNAMELEN);
./sys/ufs/ext2fs/ext2fs_vfsops.c:704: strncpy(sbp-f_fstypename,
mp-mnt_vfc-vfc_name, MFSNAMELEN);
./sys/ufs/mfs/mfs_vfsops.c:222: strncpy(sbp-f_fstypename[0],
mp-mnt_vfc-vfc_name, MFSNAMELEN);
Can be those replace safely by strlcpy without any modification to
MFSNAMELEN constant?
I thought I had seen someone reply to this on tech@ but I can't find any
evidence of that. So... *ping*?
Most places use strn{cmp,cpy} except for compat/linux/linux_misc.c so it
seems OK. However, OP's grep missed the following usage which (I imagine)
expects a nul-terminated c-string:
sys/kern/vfs_subr.c in vfs_mount_print()
(*pr)( fstype \%s\ mnton \%s\ mntfrom \%s\ mntspec \%s\\n,
mp-mnt_stat.f_fstypename, mp-mnt_stat.f_mntonname,
mp-mnt_stat.f_mntfromname, mp-mnt_stat.f_mntfromspec);
Called from ddb/db_command.c: db_show_all_{mount,vnode}s()
Producing a patch as OP suggested is simple enough, but testing for regression
is a bit of an unknown to me.
--patrick
vfs references to strncpy and MFSNAMELEN
The constant MFSNAMELEN as defined in: lib/libc/sys/getfsstat.2:#define MFSNAMELEN 16 lib/libc/sys/statfs.2:#define MFSNAMELEN 16 sys/sys/mount.h: #define MFSNAMELEN 16 defines the fs type name and, according to comments, it includes nul terminating character. The following code makes uses of strncpy and involves MFSNAMELEN ./sys/kern/vfs_subr.c:225: strncpy(mp-mnt_stat.f_fstypename, vfsp-vfc_name, MFSNAMELEN); ./sys/kern/vfs_subr.c:2272: strncpy(sbp-f_fstypename, mp-mnt_vfc-vfc_name, MFSNAMELEN); ./sys/kern/vfs_syscalls.c:243: strncpy(mp-mnt_stat.f_fstypename, vfsp-vfc_name, MFSNAMELEN); ./sys/miscfs/procfs/procfs_vfsops.c:190:strncpy(sbp-f_fstypename, mp-mnt_vfc-vfc_name, MFSNAMELEN); ./sys/msdosfs/msdosfs_vfsops.c:669: strncpy(sbp-f_fstypename, mp-mnt_vfc-vfc_name, MFSNAMELEN); ./sys/nfs/nfs_vfsops.c:646: strncpy(mp-mnt_stat.f_fstypename[0], mp-mnt_vfc-vfc_name, MFSNAMELEN); ./sys/ntfs/ntfs_vfsops.c:628: strncpy(sbp-f_fstypename, mp-mnt_vfc-vfc_name, MFSNAMELEN); ./sys/ufs/ext2fs/ext2fs_vfsops.c:704: strncpy(sbp-f_fstypename, mp-mnt_vfc-vfc_name, MFSNAMELEN); ./sys/ufs/mfs/mfs_vfsops.c:222: strncpy(sbp-f_fstypename[0], mp-mnt_vfc-vfc_name, MFSNAMELEN); Can be those replace safely by strlcpy without any modification to MFSNAMELEN constant?
Re: patch /etc/X11/xinit/xinitrc
The patch removes the unreasonable use of blank lines. If its automatically generated then the patch is useless. About the choices of the software, yes $HOME/.xinitrc is used IF it exists. Shouldnt then be the right choice to let the user choose its apps? IMHO fvwm and xterm are quite arbitrary. --- HLG Mensaje original De: Stuart Henderson Fecha:26/04/2014 06:38 (GMT-03:00) A: Héctor Luis Gimbatti CC: tech@openbsd.org Asunto: Re: patch /etc/X11/xinit/xinitrc On 2014/04/26 04:33, Héctor Luis Gimbatti wrote: I submit two patches for the file /etc/X11/xinit/xinitrc: These diffs are unreadable (generally, use diff -up for sending diffs, and include them inline) .. but based on the descriptions: 1. patch.p1 it removes extra blank lines in the file. The file is generated from /usr/xenocara/app/xinit/xinitrc.cpp; this is standard cpp(1) behaviour. It could be changed by unifdef'ing in the source file, but it is more sane to use the file direct from upstream's xinit source tree. 2. patch.p2 it removes fvwm and xterm references since there is no reason why the user should choose such applications. /etc/X11/xinit/xinitrc isn't about user choice, it is to provide sane working defaults using programs from a standard OpenBSD installation. OK so we could change it to cwm or twm and uxterm, but there would be complaints about that too. User choice would go in ~/.xinitrc.
patch /etc/X11/xinit/xinitrc
I submit two patches for the file /etc/X11/xinit/xinitrc: 1. patch.p1 it removes extra blank lines in the file. 2. patch.p2 it removes fvwm and xterm references since there is no reason why the user should choose such applications. --- HLG patch.p1 Description: patch.p1 patch.p2 Description: patch.p2
