Re: stat(1) -x option shows no setuid/setgid - patch
On Wednesday, October 6, 2010, LEVAI Daniel l...@ecentrum.hu wrote: On Tue, Oct 05, 2010 at 14:46:42 -0700, Philip Guenther wrote: On Sat, 2 Oct 2010, LEVAI Daniel wrote: [...] Mode: (104555/-r-sr-xr-x) ^^^ Hmm, that doesn't match the Linux/GNU stat behavior, which doesn't show the file-type bits, bits which no sane program looks at except via the macros in sys/stat.h. Might I suggest instead this diff? [...] $ obj/stat -x /usr/bin/passwd ./foo /dev/null File: /usr/bin/passwd Size: 26280FileType: Regular File Mode: (4555/-r-sr-xr-x) Uid: (0/root) Gid: (7/ bin) [...] That makes more sense, indeed! Fix committed... Philip Guenther
kill^Wchange kvm_get(procs|argv|envv), KERN_PROC, and struct kinfo_proc
It was pointed out that as long as we're breaking anything that's using
KERN_PROC, struct kinfo_proc, or kvm_get(procs|argv|envv), there really
isn't any reason to not change those APIs to the new forms. I.e.,
kvm_getprocs() gains another arguments (elemsize) and the struct
kinfo_proc that it returns changes to what is currently known as struct
kinfo_proc2. A #define for kinfo_proc2 and a few wrapper functions later
and nothing using the existing *2 functions or structures is broken but
we're prepped for getting rid of the ugly names instead of enshrining
them.
Tree builds cleanly with this. This doesn't switch all the in-tree
KERN_PROC2 and kvm_getproc2() callers over KERN_PROC and kvm_getprocs(),
in part to make sure the wrappers work cleanly and in part to keep this
diff down to the core required bits. Once this is in, those callers can
be switched at will (and kvm_proc.c can be simplified further, etc).
oks?
Philip Guenther
Index: sys/sys/sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.106
diff -u -p -r1.106 sysctl.h
--- sys/sys/sysctl.h19 Aug 2010 18:14:13 - 1.106
+++ sys/sys/sysctl.h29 Oct 2010 07:49:06 -
@@ -42,9 +42,7 @@
* These are for the eproc structure defined below.
*/
#ifndef _KERNEL
-#include sys/time.h
-#include sys/ucred.h
-#include sys/proc.h
+#include sys/proc.h /* for SRUN, SIDL, etc */
#include sys/resource.h
#endif
@@ -126,9 +124,7 @@ struct ctlname {
#defineKERN_HOSTID 11 /* int: host identifier */
#defineKERN_CLOCKRATE 12 /* struct: struct clockinfo */
#defineKERN_VNODE 13 /* struct: vnode structures */
-#if defined(_KERNEL) || defined(_LIBKVM)
-#defineKERN_PROC 14 /* struct: process entries */
-#endif
+/*define gap: was KERN_PROC14 */
#defineKERN_FILE 15 /* struct: file entries */
#defineKERN_PROF 16 /* node: kernel profiling info
*/
#defineKERN_POSIX1 17 /* int: POSIX.1 version */
@@ -180,7 +176,8 @@ struct ctlname {
#define KERN_INTRCNT 63 /* node: interrupt counters */
#defineKERN_WATCHDOG 64 /* node: watchdog */
#defineKERN_EMUL 65 /* node: emuls */
-#defineKERN_PROC2 66 /* struct: process entries */
+#defineKERN_PROC 66 /* struct: process entries */
+#defineKERN_PROC2 KERN_PROC /* backwards compat
name */
#defineKERN_MAXCLUSTERS67 /* number of mclusters */
#define KERN_EVCOUNT 68 /* node: event counters */
#defineKERN_TIMECOUNTER69 /* node: timecounter */
@@ -207,7 +204,7 @@ struct ctlname {
{ hostid, CTLTYPE_INT }, \
{ clockrate, CTLTYPE_STRUCT }, \
{ vnode, CTLTYPE_STRUCT }, \
- { proc, CTLTYPE_STRUCT }, \
+ { gap, 0 }, \
{ file, CTLTYPE_STRUCT }, \
{ profiling, CTLTYPE_NODE }, \
{ posix1version, CTLTYPE_INT }, \
@@ -259,7 +256,7 @@ struct ctlname {
{ intrcnt, CTLTYPE_NODE }, \
{ watchdog, CTLTYPE_NODE }, \
{ emul, CTLTYPE_NODE }, \
- { proc2, CTLTYPE_STRUCT }, \
+ { proc, CTLTYPE_STRUCT }, \
{ maxclusters, CTLTYPE_INT }, \
{ evcount, CTLTYPE_NODE }, \
{ timecounter, CTLTYPE_NODE }, \
@@ -308,43 +305,7 @@ struct ctlname {
#define KERN_PROC_NENV 4
/*
- * KERN_PROC subtype ops return arrays of augmented proc structures:
- */
-struct kinfo_proc {
- struct proc kp_proc; /* proc structure */
- struct eproc {
- struct proc *e_paddr; /* address of proc */
- struct session *e_sess;/* session pointer */
- struct pcred e_pcred; /* process credentials */
- struct ucred e_ucred; /* current credentials */
- struct vmspace e_vm; /* address space */
- struct pstats e_pstats;/* process stats */
- int e_pstats_valid; /* pstats valid? */
- pid_t e_ppid; /* parent process id */
- pid_t e_pgid; /* process group id */
- short e_jobc; /* job control counter */
- dev_t e_tdev; /* controlling tty dev */
- pid_t e_tpgid;/* tty process group id */
- struct session *e_tsess; /* tty session pointer */
-#defineWMESGLEN7
- chare_wmesg[WMESGLEN+1];/* wchan message */
- segsz_t e_xsize;/* text size */
- short e_xrssize; /* text rss */
- short
sync adduser with installer
The installer defaults to creating accounts with group users, adduser
creates a group for each user. Sync the two.
Takes effect only if /etc/addusers.conf is regenerated, ie. new
installations.
Index: adduser.perl
===
RCS file: /srv/boron/data/vcs/cvs/openbsd/src/usr.sbin/adduser/adduser.perl,v
retrieving revision 1.53
diff -u -p -r1.53 adduser.perl
--- adduser.perl3 Jan 2007 15:26:04 - 1.53
+++ adduser.perl29 Oct 2010 08:38:27 -
@@ -102,7 +102,7 @@ sub variables {
$defaultshell = 'ksh'; # defaultshell if not empty
$group_uniq = 'USER';
-$defaultgroup = $group_uniq;# login groupname, $group_uniq means username
+$defaultgroup = 'users'; # login groupname, $group_uniq means username
$defaultclass = 'default'; # default user login class
$uid_start = 1000; # new users get this uid
Compactas Sumergibles
Olympus 560WP USD 165 Olympus 6010 USD 275,60 Panasonic TS10 USD 360 Panasonic TS2 USD 430 Sony TX5 USD 430
Re: [PATCH] tcpdump - Wrong MDNS QU bit interpretation.
On 27 October 2010 21:37, Christiano F. Haesbaert haesba...@haesbaert.org wrote: The 0x8000 bit in a question isn't a cache flush indication. It's the QU bit, indicating the question accepts a unicast response, although it's the same bit in the class field, they have completely different meanings when in a RR or in a query. The draft refers it as the QU (Question Unicast) bit, so I've changed it to QU. Index: print-domain.c === RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v retrieving revision 1.17 diff -d -u -p -w -r1.17 print-domain.c --- print-domain.c 27 Oct 2009 23:59:55 - 1.17 +++ print-domain.c 27 Oct 2010 23:33:19 - @@ -342,7 +342,7 @@ ns_qprint(register const u_char *cp, reg i = EXTRACT_16BITS(cp); cp += 2; if (is_mdns i == (C_IN|C_CACHE_FLUSH)) - printf( (Cache flush)); + printf( (QU)); else if (i != C_IN) printf( %s, tok2str(ns_class2str, (Class %d), i)); Just some more info, I've tested it on a linux box and it outputs QU (Unicast) or QM (Multicast), I don't see a point in outputing QM as this is the default/normal question.
Re: sync adduser with installer
On Fri, Oct 29, 2010 at 02:29:50PM +0200, Ingo Schwarze wrote: Hi Tobias, i'm not sure as i don't use tools like adduser(8) and useradd(8), and i doubt they are widely used among developers anyway. I think they are around mostly because some people are used to them from other systems. Moin Ingo, useradd(8) is a different utility, it defaults to the users group unless specified otherwise. It is ridiculous that we have two utilities like this -- besides being inconsistant... they both suck in other ways as well. So, gratuitously changing the defaults is not necessarily a wise move. As far as i can see, FreeBSD adduser(8) defaults to per-user-groups as well, even though it's a different implementation. Very probably, that's what people expect from this particular tool. Of course, in case adduser(8) users like the change, i'm not opposed to it. Well I'm an adduser(8) user and I don't like the default, since it's inconsistent with the rest of the system. On OpenBSD, I expect it to behave like the other user management tools and especially the install script. I agree. It's not some mandated POSIX behaviour, so I'm not that concerned with compatability to XMLBsd in this particular case. I agree. This topic came up last year as well, including the same useradd/adduser confusion: http://kerneltrap.org/mailarchive/openbsd-tech/2009/5/8/5660874 useradd really does that? A new group for every user? I think that is stupid behaviour. It is stupid behaviour, and I like the patch. If both these programs go simpler and more alike, in the long term that would be better for everyone.
Re: Ralink RT3090 should work now
On Sun, Oct 24, 2010 at 11:14 AM, Andres Perera andre...@zoho.com wrote: On Sat, Oct 23, 2010 at 10:02 AM, Damien Bergamini damien.bergam...@free.fr wrote: I finally found some time to finish RT3090 support in ral(4). If you have such a device, please test the driver in -current and report success/failure directly to me. Haven't tested it yet, but thanks a ton anyway. Will report as soon as I finish syncing cvs. Works great, thanks again.
Re: sync adduser with installer
On Fri, Oct 29, 2010 at 10:52:46AM +0200, Tobias Ulmer wrote: The installer defaults to creating accounts with group users, adduser creates a group for each user. Sync the two. Takes effect only if /etc/addusers.conf is regenerated, ie. new installations. This should lead to at least the appended change to the manpage. This is a minimal fix. The very feature of removing the group might not be that relevant, then. This might look silly to these who know but why are there two programs to do the same thing (save the useradd is not interactive) ? Cheers. hyjial. Index: adduser.8 === RCS file: /cvs/src/usr.sbin/adduser/adduser.8,v retrieving revision 1.39 diff -u -r1.39 adduser.8 --- adduser.8 31 May 2007 19:20:21 - 1.39 +++ adduser.8 29 Oct 2010 17:37:48 - @@ -209,9 +209,7 @@ Removes the user from the password database and all groups in the group database. If a group becomes empty and its name is the same as the username, -the group is removed (this complements -.Nm adduser Ns 's -unique per-user groups). +the group is removed. .It Recursively deletes all files in the user's home directory and removes the directory itself (provided the directory actually belongs to the user).
Re: sync adduser with installer
On Fri, Oct 29, 2010 at 9:40 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: On Fri, Oct 29, 2010 at 02:29:50PM +0200, Ingo Schwarze wrote: ... This topic came up last year as well, including the same useradd/adduser confusion: http://kerneltrap.org/mailarchive/openbsd-tech/2009/5/8/5660874 useradd really does that? A new group for every user? I think that is stupid behaviour. It is stupid behaviour, and I like the patch. If both these programs go simpler and more alike, in the long term that would be better for everyone. Back in my pure sysadmin days, I found that when users all (or almost all) share a default group like users, then it isn't easy enough for normal users to leverage other groups for shared access to files and directories. Because the default group is widely shared, everyone runs with a umask of 077 or 022; 'group' is effectively 'other'. As a result, users trying to share stuff via secondary groups have to remember to change umask or use chmod all the time. *I* didn't always remember to do that and I was the sysadmin; the teachers and students certainly didn't get it right consistently. Group-per-user setups solve this by letting people safely have a umask of 007 or 002. When they do work in a directory whose group is a secondary group, the resulting files are (and stay) writable by the group**. Permitting that change in default umask eliminates the requirement for manual changes and their cognitive load as the user moves between projects and directories. Fewer forgets and mistakes meant fewer emails to root asking for me to fix the perms on some file while so-and-so was on vacation, etc. Philip Guenther ** This was mostly on Solaris and Linux systems, so a pass across the system to do chmod g+s on all directories was necessary to get BSD-style new files inherit group from directory, but that was a one-time cost.
Todo para Pintar - Pistolas y Aerógrafos
$360Pistola de pintar HVLP Premiun CCapacidad 600 cc / Presion Maxima 3 Bar / Uso Profesional / Incluye Manometro y Kit de Desarme y Limpieza $ 190Pistola de pintar latex y texturados Pintura Latex y Texturador / Para Compresor de 2,5 HP / Ideal Pintar Durlock o Yeso Presion de Trabajo 50 - 70 PSI / Entrada 1/4 Laacute;pizAeroacute;grafo Kit $110 Pistola de pintar Classic $140 Pistola de pintar Alta viscocidad $390 Micro aeroacute;grafo $ 225 Pistolade pintar Sistema succioacute;n S280
Re: sync adduser with installer
* Philip Guenther guent...@gmail.com [2010-10-29 19:48]: Back in my pure sysadmin days, I found that when users all (or almost all) share a default group like users, then it isn't easy enough for normal users to leverage other groups for shared access to files and directories. Because the default group is widely shared, everyone runs with a umask of 077 or 022; 'group' is effectively 'other'. As a result, users trying to share stuff via secondary groups have to remember to change umask or use chmod all the time. *I* didn't always remember to do that and I was the sysadmin; the teachers and students certainly didn't get it right consistently. Group-per-user setups solve this by letting people safely have a umask of 007 or 002. When they do work in a directory whose group is a secondary group, the resulting files are (and stay) writable by the group**. Permitting that change in default umask eliminates the requirement for manual changes and their cognitive load as the user moves between projects and directories. Fewer forgets and mistakes meant fewer emails to root asking for me to fix the perms on some file while so-and-so was on vacation, etc. I have to agree here. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: sync adduser with installer
On Fri, Oct 29, 2010 at 11:25 AM, Henning Brauer lists-openbsdt...@bsws.de wrote: * Philip Guenther guent...@gmail.com [2010-10-29 19:48]: Group-per-user setups solve this by letting people safely have a umask of 007 or 002. When they do work in a directory whose group is a secondary group, the resulting files are (and stay) writable by the group**. Permitting that change in default umask eliminates the requirement for manual changes and their cognitive load as the user moves between projects and directories. Fewer forgets and mistakes meant fewer emails to root asking for me to fix the perms on some file while so-and-so was on vacation, etc. I have to agree here. Same here. Really, I'm surprised that anyone is using the 'users' group at all these days, especially on OpenBSD. If all users are in the same group, group permissions are no different from world permissions. The book Mastering FreeBSD and OpenBSD security talks about per-user groups being the best option here: http://books.google.com/books?id=gqKwaHmXp4YClpg=PA119ots=jioDgXRI6Tdq=uni x%20%22per-user%20groups%22pg=PA119#v=onepageq=unix%20%22per-user%20groups% 22f=false Add the FreeBSD manual here: http://www.freebsd.org/cgi/man.cgi?query=addusersektion=8#UNIQUE_GROUPS useradd/del/mod/info were meant to be low-level tools for scripts to use. adduser and rmuser are higher-level and can be used interactively. rmuser for example removes a users cron/at jobs and /var/mail file and adduser can send a welcome email to the user - userdel/add don't. I don't add users with the OpenBSD installer because it does the wrong thing and should be fixed to use the adduser defaults. :) Daniel
less stupid kshrc example
Defining a bunch of functions just to update the term title is
ridiculous.
--- src/etc/ksh.kshrc.orig Fri Oct 29 21:40:51 2010
+++ src/etc/ksh.kshrc Fri Oct 29 21:51:48 2010
@@ -45,16 +45,7 @@
HOSTNAME=${HOSTNAME:-`uname -n`}
HOST=${HOSTNAME%%.*}
- PROMPT=$USER:!$PS1S
- #PROMPT=$u...@$host:!$PS1S
- PPROMPT='$USER:$PWD:!'$PS1S
- #PPROMPT='$u...@$host:$PWD:!'$PS1S
- PS1=$PPROMPT
- # $TTY is the tty we logged in on,
- # $tty is that which we are in now (might by pty)
- tty=`tty`
- tty=`basename $tty`
- TTY=${TTY:-$tty}
+ PS1='\...@\h:\w \$ '
set -o emacs
@@ -70,82 +61,29 @@
;;
esac
case $TERM in
- sun*-s)
- # sun console with status line
- if [ $tty != $console ]; then
- # ilabel
- ILS='\033]L'; ILE='\033\\'
- # window title bar
- WLS='\033]l'; WLE='\033\\'
- fi
+ dtterm*|screen*|rxvt*|xterm*)
+ ILS=\e]1;
+ ILE=\a
+ WLS=\e]2;
+ WLE=\a
;;
- xterm*)
- ILS='\033]1;'; ILE='\007'
- WLS='\033]2;'; WLE='\007'
- parent=`ps -ax 2/dev/null | grep $PPID | grep -v grep`
- case $parent in
- *telnet*)
- export TERM=xterms;;
- esac
+ ''|dumb|vt220)
+ true
;;
- *) ;;
+ *)
+ if tput hs /dev/null 21; then
+ WLS=`tput ts`
+ WLE=`tput fs`
+ fi
+ ;;
esac
- # do we want window decorations?
- if [ $ILS ]; then
- ilabel () { print -n ${ILS}$*${ILE}/dev/tty; }
- label () { print -n ${WLS}$*${WLE}/dev/tty; }
-
- alias stripe='label $u...@$host ($tty) - $PWD'
- alias istripe='ilabel $u...@$host ($tty)'
-
- wftp () { ilabel ftp $*; ftp $@; eval istripe; }
- wcd () { \cd $@ eval stripe; }
- wssh ()
- {
- local rc
- ssh $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wtelnet ()
- {
- local rc
- telnet $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wrlogin ()
- {
- local rc
- rlogin $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wsu ()
- {
- local rc
- su $@
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- alias su=wsu
- alias cd=wcd
- alias ftp=wftp
- alias ssh=wssh
- alias telnet=wtelnet
- alias rlogin=wrlogin
- eval stripe
- eval istripe
- PS1=$PROMPT
+ if [ -n $ILS ]; then
+ PS1=$ps1\[$il...@\h$ile\]
fi
+ if [ -n $WLS ]; then
+ PS1=$ps1\[$wl...@\h \w$WLE\]
+ fi
+ unset ILS ILE WLS WLE
alias quit=exit
alias cls=clear
alias logout=exit
OpenBSD Course online
Is there someone who can give me OpenBSD Administration course online (practice using ssh) ? That will cover BSDP Objectives. Thanks
Re: sync adduser with installer
Daniel wrote: Same here. Really, I'm surprised that anyone is using the 'users' group at all these days, especially on OpenBSD. If all users are in the same group, group permissions are no different from world permissions. I believe the real problem here is that you're allowing users on your systems that are incapable of properly setting the group/world permissions of their home directories. It's also a possibility that you are derelict in your duties as a systems administrator. No cookies for you. -Bryan.
