Re: usermod: lock/unlock local password

2012-09-11 Thread Eugene Yunak
On 10 September 2012 18:01, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
 Hi.

 This diff adds 2 new options to usermod(8):
 -U to unlock a user's password
 -Z to lock a user's password

 In effect locking/unlocking the password means to add a '!' in front of
 the encrypted entry in master.passwd.
 Note that this disable the _password_ not the account of course (you
 could still connect using ssh+key for e.g.).

 That said, I have some use for it and would like to be able to have this
 if at all possible.
 Behavior is basically the same as Linux's usermod(8) except that I am
 using -Z for locking the password (-Z is for SElinux in Linux land and
 -L is used instead but we use it ourselves for the login class).

 Comments?





 Index: user.c
 ===
 RCS file: /cvs/src/usr.sbin/user/user.c,v
 retrieving revision 1.90
 diff -u -r1.90 user.c
 --- user.c  29 Jan 2012 08:38:54 -  1.90
 +++ user.c  10 Sep 2012 15:00:21 -
 @@ -100,7 +100,9 @@
 F_UID   = 0x0400,
 F_USERNAME  = 0x0800,
 F_CLASS = 0x1000,
 -   F_SETSECGROUP   = 0x4000
 +   F_SETSECGROUP   = 0x4000,
 +   F_PWLOCK= 0x8000,
 +   F_PWUNLOCK  = 0x1
  };

  #define CONFFILE   /etc/usermgmt.conf
 @@ -1339,11 +1341,14 @@
 struct group*grp;
 const char  *homedir;
 charbuf[LINE_MAX];
 +   charlocked_str[] = !;
 +   charpw_len[PasswordLength + 1];
 size_t  colonc, loginc;
 size_t  cc;
 FILE*master;
 charnewdir[MaxFileNameLen];
 char*colon;
 +   char*pw_tmp;
 int len;
 int masterfd;
 int ptmpfd;
 @@ -1359,6 +1364,9 @@
 if (!is_local(login_name, _PATH_MASTERPASSWD)) {
 errx(EXIT_FAILURE, User `%s' must be a local user, 
 login_name);
 }
 +   if ((up-u_flags  (F_PWLOCK | F_PWUNLOCK))  (pwp-pw_uid == 0)) {
 +   errx(EXIT_FAILURE, (un)locking is not supported for `%s', 
 pwp-pw_name);
 +   }
 /* keep dir name in case we need it for '-m' */
 homedir = pwp-pw_dir;

 @@ -1410,6 +1418,29 @@
 pwp-pw_passwd = up-u_password;
 }
 }
 +   if (up-u_flags  F_PWLOCK) {
 +   if (strncmp(pwp-pw_passwd, locked_str, 
 sizeof(locked_str)-1) == 0) {
 +warnx(user '%s' is already locked, 
 pwp-pw_name);
 +   } else {
 +   pw_tmp = malloc(strlen(pwp-pw_passwd) + 
 sizeof(locked_str));
 +   if (pw_tmp == NULL) {
 +   (void) close(ptmpfd);
 +   pw_abort();
 +   errx(EXIT_FAILURE, cannot allocate 
 memory);
 +   }
 +   strlcpy(pw_tmp, locked_str, sizeof(pw_len));
 +   strlcat(pw_tmp, pwp-pw_passwd, 
 sizeof(pw_len));
 +   pwp-pw_passwd = pw_tmp;
 +   free (pw_tmp);
 +   }
 +   }
 +   if (up-u_flags  F_PWUNLOCK) {
 +   if (strncmp(pwp-pw_passwd, locked_str, 
 sizeof(locked_str)-1) != 0) {
 +   warnx(user '%s' is not locked, 
 pwp-pw_name);
 +   } else {
 +   pwp-pw_passwd += sizeof(locked_str)-1;
 +   }
 +   }
 if (up-u_flags  F_UID) {
 /* check uid isn't already allocated */
 if (!(up-u_flags  F_DUPUID)  
 getpwuid((uid_t)(up-u_uid)) != NULL) {
 @@ -1617,7 +1648,7 @@
 [-p password] [-r low..high]\n
[-s shell] [-u uid] user\n, prog);
 } else if (strcmp(prog, usermod) == 0) {
 -   (void) fprintf(stderr, usage: %s [-mov] 
 +   (void) fprintf(stderr, usage: %s [-UZmov] 
 [-c comment] [-d home-directory] [-e expiry-time]\n
[-f inactive-time] 
 [-G secondary-group[,group,...]]\n
 @@ -1788,7 +1819,7 @@
 free(u.u_primgrp);
 u.u_primgrp = NULL;
 have_new_user = 0;
 -   while ((c = getopt(argc, argv, G:L:S:c:d:e:f:g:l:mop:s:u:v)) != -1) 
 {
 +   while ((c = getopt(argc, argv, G:L:S:UZc:d:e:f:g:l:mop:s:u:v)) != 
 -1) {
 switch(c) {
 case 'G':
 while ((u.u_groupv[u.u_groupc] = strsep(optarg, 
 ,)) != NULL 
 @@ -1814,6 +1845,12 @@
 }
 u.u_flags |= 

Re: usermod: lock/unlock local password

2012-09-11 Thread Antoine Jacoutot
On Tue, Sep 11, 2012 at 09:33:56AM +0300, Eugene Yunak wrote:
 On 10 September 2012 18:01, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
  Hi.
 
  This diff adds 2 new options to usermod(8):
  -U to unlock a user's password
  -Z to lock a user's password
 
  In effect locking/unlocking the password means to add a '!' in front of
  the encrypted entry in master.passwd.
  Note that this disable the _password_ not the account of course (you
  could still connect using ssh+key for e.g.).
 
  That said, I have some use for it and would like to be able to have this
  if at all possible.
  Behavior is basically the same as Linux's usermod(8) except that I am
  using -Z for locking the password (-Z is for SElinux in Linux land and
  -L is used instead but we use it ourselves for the login class).
 
  Comments?
 
 
 
 
 
  Index: user.c
  ===
  RCS file: /cvs/src/usr.sbin/user/user.c,v
  retrieving revision 1.90
  diff -u -r1.90 user.c
  --- user.c  29 Jan 2012 08:38:54 -  1.90
  +++ user.c  10 Sep 2012 15:00:21 -
  @@ -100,7 +100,9 @@
  F_UID   = 0x0400,
  F_USERNAME  = 0x0800,
  F_CLASS = 0x1000,
  -   F_SETSECGROUP   = 0x4000
  +   F_SETSECGROUP   = 0x4000,
  +   F_PWLOCK= 0x8000,
  +   F_PWUNLOCK  = 0x1
   };
 
   #define CONFFILE   /etc/usermgmt.conf
  @@ -1339,11 +1341,14 @@
  struct group*grp;
  const char  *homedir;
  charbuf[LINE_MAX];
  +   charlocked_str[] = !;
  +   charpw_len[PasswordLength + 1];
  size_t  colonc, loginc;
  size_t  cc;
  FILE*master;
  charnewdir[MaxFileNameLen];
  char*colon;
  +   char*pw_tmp;
  int len;
  int masterfd;
  int ptmpfd;
  @@ -1359,6 +1364,9 @@
  if (!is_local(login_name, _PATH_MASTERPASSWD)) {
  errx(EXIT_FAILURE, User `%s' must be a local user, 
  login_name);
  }
  +   if ((up-u_flags  (F_PWLOCK | F_PWUNLOCK))  (pwp-pw_uid == 0)) {
  +   errx(EXIT_FAILURE, (un)locking is not supported for `%s', 
  pwp-pw_name);
  +   }
  /* keep dir name in case we need it for '-m' */
  homedir = pwp-pw_dir;
 
  @@ -1410,6 +1418,29 @@
  pwp-pw_passwd = up-u_password;
  }
  }
  +   if (up-u_flags  F_PWLOCK) {
  +   if (strncmp(pwp-pw_passwd, locked_str, 
  sizeof(locked_str)-1) == 0) {
  +warnx(user '%s' is already locked, 
  pwp-pw_name);
  +   } else {
  +   pw_tmp = malloc(strlen(pwp-pw_passwd) + 
  sizeof(locked_str));
  +   if (pw_tmp == NULL) {
  +   (void) close(ptmpfd);
  +   pw_abort();
  +   errx(EXIT_FAILURE, cannot allocate 
  memory);
  +   }
  +   strlcpy(pw_tmp, locked_str, sizeof(pw_len));
  +   strlcat(pw_tmp, pwp-pw_passwd, 
  sizeof(pw_len));
  +   pwp-pw_passwd = pw_tmp;
  +   free (pw_tmp);
  +   }
  +   }
  +   if (up-u_flags  F_PWUNLOCK) {
  +   if (strncmp(pwp-pw_passwd, locked_str, 
  sizeof(locked_str)-1) != 0) {
  +   warnx(user '%s' is not locked, 
  pwp-pw_name);
  +   } else {
  +   pwp-pw_passwd += sizeof(locked_str)-1;
  +   }
  +   }
  if (up-u_flags  F_UID) {
  /* check uid isn't already allocated */
  if (!(up-u_flags  F_DUPUID)  
  getpwuid((uid_t)(up-u_uid)) != NULL) {
  @@ -1617,7 +1648,7 @@
  [-p password] [-r low..high]\n
 [-s shell] [-u uid] user\n, prog);
  } else if (strcmp(prog, usermod) == 0) {
  -   (void) fprintf(stderr, usage: %s [-mov] 
  +   (void) fprintf(stderr, usage: %s [-UZmov] 
  [-c comment] [-d home-directory] [-e expiry-time]\n
 [-f inactive-time] 
  [-G secondary-group[,group,...]]\n
  @@ -1788,7 +1819,7 @@
  free(u.u_primgrp);
  u.u_primgrp = NULL;
  have_new_user = 0;
  -   while ((c = getopt(argc, argv, G:L:S:c:d:e:f:g:l:mop:s:u:v)) != 
  -1) {
  +   while ((c = getopt(argc, argv, G:L:S:UZc:d:e:f:g:l:mop:s:u:v)) != 
  -1) {
  switch(c) {
  case 'G':
 

Re: usermod: lock/unlock local password

2012-09-11 Thread Eugene Yunak
On 11 September 2012 09:37, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
 On Tue, Sep 11, 2012 at 09:33:56AM +0300, Eugene Yunak wrote:
 On 10 September 2012 18:01, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
  Hi.
 
  This diff adds 2 new options to usermod(8):
  -U to unlock a user's password
  -Z to lock a user's password
 
  In effect locking/unlocking the password means to add a '!' in front of
  the encrypted entry in master.passwd.
  Note that this disable the _password_ not the account of course (you
  could still connect using ssh+key for e.g.).
 
  That said, I have some use for it and would like to be able to have this
  if at all possible.
  Behavior is basically the same as Linux's usermod(8) except that I am
  using -Z for locking the password (-Z is for SElinux in Linux land and
  -L is used instead but we use it ourselves for the login class).
 
  Comments?

 Hi,

 Isn't think better placed in passwd?
 At least Linux and Solaris (since 5.6 i believe) have this as -l and
 -u in passwd(1),
 so this might be a better option to keep it consistent with other
 systems. HP-UX
 only implements -l; I haven't checked others.

 It is consistent; this is how usermod works in linux as well.

Isn't it better to be consistent with most Unix systems and not just Linux?
The world is Linux-centric enough already and an OpenBSD should know it
better than anyone else ;)

 OpenBSD passwd already uses -l to restrict passwd to local files only though 
 so
 you would still need to use a different letter (as you do with
 usermod) but at least
 passwd(1) is where most unix admins would look for this option first.

 This diff is for the usermod part, not passwd; both are different things.

I don't get it - how are they different things? Both manipulate shadow.


-- 
The best the little guy can do is what
the little guy does right



Re: usermod: lock/unlock local password

2012-09-11 Thread Antoine Jacoutot
On Tue, Sep 11, 2012 at 10:23:13AM +0300, Eugene Yunak wrote:
 On 11 September 2012 09:37, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
  On Tue, Sep 11, 2012 at 09:33:56AM +0300, Eugene Yunak wrote:
  On 10 September 2012 18:01, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
   Hi.
  
   This diff adds 2 new options to usermod(8):
   -U to unlock a user's password
   -Z to lock a user's password
  
   In effect locking/unlocking the password means to add a '!' in front of
   the encrypted entry in master.passwd.
   Note that this disable the _password_ not the account of course (you
   could still connect using ssh+key for e.g.).
  
   That said, I have some use for it and would like to be able to have this
   if at all possible.
   Behavior is basically the same as Linux's usermod(8) except that I am
   using -Z for locking the password (-Z is for SElinux in Linux land and
   -L is used instead but we use it ourselves for the login class).
  
   Comments?
 
  Hi,
 
  Isn't think better placed in passwd?
  At least Linux and Solaris (since 5.6 i believe) have this as -l and
  -u in passwd(1),
  so this might be a better option to keep it consistent with other
  systems. HP-UX
  only implements -l; I haven't checked others.
 
  It is consistent; this is how usermod works in linux as well.
 
 Isn't it better to be consistent with most Unix systems and not just Linux?
 The world is Linux-centric enough already and an OpenBSD should know it
 better than anyone else ;)

FreeBSD and NetBSD do the same (i.e. lock using usermod).
I don't really care about HP-UX compatibility... and I don't understand your 
comment about OpenBSD should know it better; what is it you want exactly?
As I said, I have a use for it using usermod(8). If you have a use for it with 
passwd(1) then provide a diff.

Each Unix has a slightly different useradd/mod/del ... command you know.

  OpenBSD passwd already uses -l to restrict passwd to local files only 
  though so
  you would still need to use a different letter (as you do with
  usermod) but at least
  passwd(1) is where most unix admins would look for this option first.
 
  This diff is for the usermod part, not passwd; both are different things.
 
 I don't get it - how are they different things? Both manipulate shadow.

And so does vipw(8).
Look this is a diff for _usermod_. If you want to add flags to passwd(1), then 
just do so, I have no problem with it.

-- 
Antoine



Re: usermod: lock/unlock local password

2012-09-11 Thread Ted Unangst
On Mon, Sep 10, 2012 at 17:01, Antoine Jacoutot wrote:

 In effect locking/unlocking the password means to add a '!' in front of
 the encrypted entry in master.passwd.
 Note that this disable the _password_ not the account of course (you
 could still connect using ssh+key for e.g.).

I am very concerned that this violates the principle of least surprise.



Re: usermod: lock/unlock local password

2012-09-11 Thread Antoine Jacoutot
On Tue, Sep 11, 2012 at 03:47:57AM -0400, Ted Unangst wrote:
 On Mon, Sep 10, 2012 at 17:01, Antoine Jacoutot wrote:
 
  In effect locking/unlocking the password means to add a '!' in front of
  the encrypted entry in master.passwd.
  Note that this disable the _password_ not the account of course (you
  could still connect using ssh+key for e.g.).
 
 I am very concerned that this violates the principle of least surprise.

Well I can extend the man page accordingly if you want. But I mean it has the 
same result as using vipw(8).
Disabling a password has always been different than disabling an account.

-- 
Antoine



Re: usermod: lock/unlock local password

2012-09-11 Thread Stuart Henderson
On 2012/09/11 03:47, Ted Unangst wrote:
 On Mon, Sep 10, 2012 at 17:01, Antoine Jacoutot wrote:
 
  In effect locking/unlocking the password means to add a '!' in front of
  the encrypted entry in master.passwd.
  Note that this disable the _password_ not the account of course (you
  could still connect using ssh+key for e.g.).
 
 I am very concerned that this violates the principle of least surprise.
 

This is already common enough that /usr/libexec/security checks for
alternative access methods if the password is disabled (i.e. the crypted
password is neither 13 chars long nor starts with $[0-9a-f]$) but the
shell is valid.



Re: usermod: lock/unlock local password

2012-09-11 Thread Antoine Jacoutot
On Tue, Sep 11, 2012 at 03:47:57AM -0400, Ted Unangst wrote:
 On Mon, Sep 10, 2012 at 17:01, Antoine Jacoutot wrote:
 
  In effect locking/unlocking the password means to add a '!' in front of
  the encrypted entry in master.passwd.
  Note that this disable the _password_ not the account of course (you
  could still connect using ssh+key for e.g.).
 
 I am very concerned that this violates the principle of least surprise.

Stuart proposed that my diff appends/remove '-' from the user shell.
I think this is a good idea, I'll send another diff later.

-- 
Antoine



Re: usermod: lock/unlock local password

2012-09-11 Thread Todd T. Fries
I like the direction this is going.  I've implemented a shell
equivalent in the past for one scenario, but having it in the
tools directly definitely makes life easier.

1000 admins can implement it differently, but this at least
provides consistent behavior and provides a mechanism for
automation that is robust.

I look forward to the next version with '-' added/removed to/from
the users shell ;-)

Thanks,

Penned by Antoine Jacoutot on 20120910 10:01.13, we have:
| Hi.
| 
| This diff adds 2 new options to usermod(8):
| -U to unlock a user's password
| -Z to lock a user's password
| 
| In effect locking/unlocking the password means to add a '!' in front of
| the encrypted entry in master.passwd.
| Note that this disable the _password_ not the account of course (you
| could still connect using ssh+key for e.g.).
| 
| That said, I have some use for it and would like to be able to have this
| if at all possible.
| Behavior is basically the same as Linux's usermod(8) except that I am
| using -Z for locking the password (-Z is for SElinux in Linux land and
| -L is used instead but we use it ourselves for the login class).
| 
| Comments?
| 
| 
| 
| 
| 
| Index: user.c
| ===
| RCS file: /cvs/src/usr.sbin/user/user.c,v
| retrieving revision 1.90
| diff -u -r1.90 user.c
| --- user.c29 Jan 2012 08:38:54 -  1.90
| +++ user.c10 Sep 2012 15:00:21 -
| @@ -100,7 +100,9 @@
|   F_UID   = 0x0400,
|   F_USERNAME  = 0x0800,
|   F_CLASS = 0x1000,
| - F_SETSECGROUP   = 0x4000
| + F_SETSECGROUP   = 0x4000,
| + F_PWLOCK= 0x8000,
| + F_PWUNLOCK  = 0x1
|  };
|  
|  #define CONFFILE /etc/usermgmt.conf
| @@ -1339,11 +1341,14 @@
|   struct group*grp;
|   const char  *homedir;
|   charbuf[LINE_MAX];
| + charlocked_str[] = !;
| + charpw_len[PasswordLength + 1];
|   size_t  colonc, loginc;
|   size_t  cc;
|   FILE*master;
|   charnewdir[MaxFileNameLen];
|   char*colon;
| + char*pw_tmp;
|   int len;
|   int masterfd;
|   int ptmpfd;
| @@ -1359,6 +1364,9 @@
|   if (!is_local(login_name, _PATH_MASTERPASSWD)) {
|   errx(EXIT_FAILURE, User `%s' must be a local user, 
login_name);
|   }
| + if ((up-u_flags  (F_PWLOCK | F_PWUNLOCK))  (pwp-pw_uid == 0)) {
| + errx(EXIT_FAILURE, (un)locking is not supported for `%s', 
pwp-pw_name);
| + }
|   /* keep dir name in case we need it for '-m' */
|   homedir = pwp-pw_dir;
|  
| @@ -1410,6 +1418,29 @@
|   pwp-pw_passwd = up-u_password;
|   }
|   }
| + if (up-u_flags  F_PWLOCK) {
| + if (strncmp(pwp-pw_passwd, locked_str, 
sizeof(locked_str)-1) == 0) {
| +  warnx(user '%s' is already locked, 
pwp-pw_name);
| + } else {
| + pw_tmp = malloc(strlen(pwp-pw_passwd) + 
sizeof(locked_str));
| + if (pw_tmp == NULL) {
| + (void) close(ptmpfd);
| + pw_abort();
| + errx(EXIT_FAILURE, cannot allocate 
memory);
| + }
| + strlcpy(pw_tmp, locked_str, sizeof(pw_len));
| + strlcat(pw_tmp, pwp-pw_passwd, sizeof(pw_len));
| + pwp-pw_passwd = pw_tmp;
| + free (pw_tmp);
| + }
| + }
| + if (up-u_flags  F_PWUNLOCK) {
| + if (strncmp(pwp-pw_passwd, locked_str, 
sizeof(locked_str)-1) != 0) {
| + warnx(user '%s' is not locked, pwp-pw_name);
| + } else {
| + pwp-pw_passwd += sizeof(locked_str)-1;
| + }
| + }
|   if (up-u_flags  F_UID) {
|   /* check uid isn't already allocated */
|   if (!(up-u_flags  F_DUPUID)  
getpwuid((uid_t)(up-u_uid)) != NULL) {
| @@ -1617,7 +1648,7 @@
|   [-p password] [-r low..high]\n
|  [-s shell] [-u uid] user\n, prog);
|   } else if (strcmp(prog, usermod) == 0) {
| - (void) fprintf(stderr, usage: %s [-mov] 
| + (void) fprintf(stderr, usage: %s [-UZmov] 
|   [-c comment] [-d home-directory] [-e expiry-time]\n
|  [-f inactive-time] 
|   [-G secondary-group[,group,...]]\n
| @@ -1788,7 +1819,7 @@
|   free(u.u_primgrp);
|   u.u_primgrp = NULL;
|   have_new_user = 0;
| - while ((c = getopt(argc, argv, 

Coaching y Multihabilidades de Supervisión

2012-09-11 Thread Lic. Yinela Cheribin
Coaching y Multihabilidades de Supervisión
SEMINARIO ONLINE EN VIVO este 27 de Septiembre de 2012.
El Nuevo concepto de Coaching y Multihabilidades le ayudará notablemente a
mejorar y aumentar su capacidad de trabajo, le brindará las técnicas más
modernas y efectivas que usted necesita para destacar en su organización!

En este Seminario ONLINE en Vivo usted aprenderá:

•¿Cómo se transforma un Supervisor en un Coach - Multihabilidades?
•Métodos prácticos para planear, organizar y controlar su trabajo  y el de sus
colaboradores.
•¿Cuándo y cómo delegar y facultar a sus colaboradores?
•Establecer una cultura de previsión, eficiencia y proactividad hacia la
solución de problemas.
•Técnicas avanzadas para medir el trabajo, controlar la eficiencia y
rendimiento de la mano de obra.
•¿Cómo administrar y distribuir mejor las cargas de trabajo? - Estándares  de
tiempo.

Adquiera la información completa y sin compromiso, solo responda este correo
con asunto -Deseo Folleto Coaching o Comuníquese al (507) 279-1083 / 279-0258
/ 279-0887 - y a la brevedad lo recibirá!
ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS
ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar
y automáticamente quedará fuera de nuestras listas. Este correo ha sido
enviado a: tech@openbsd.org



Re: usermod: lock/unlock local password

2012-09-11 Thread Antoine Jacoutot
On Mon, Sep 10, 2012 at 05:01:13PM +0200, Antoine Jacoutot wrote:
 Hi.
 
 This diff adds 2 new options to usermod(8):
 -U to unlock a user's password
 -Z to lock a user's password
 
 In effect locking/unlocking the password means to add a '!' in front of
 the encrypted entry in master.passwd.
 Note that this disable the _password_ not the account of course (you
 could still connect using ssh+key for e.g.).
 
 That said, I have some use for it and would like to be able to have this
 if at all possible.
 Behavior is basically the same as Linux's usermod(8) except that I am
 using -Z for locking the password (-Z is for SElinux in Linux land and
 -L is used instead but we use it ourselves for the login class).

Ok new diff that does something slightly different.
Instead of putting a '!' in front of the password (which confused people), 
lock/unlock means appending/removing a dash to the user's login shell.
While this is non standard behavior (but as I mentionned in a previous mail, 
usermod(8) is already not standard accross unices) I think it is better because:
- account is locked, period (no local login, no remote login -- no surprise for 
tedu ;-) )
- no values are touched
  (e.g. one could disable an account by using 'usermod -e 1' but when he wants 
to re-enable the account he'll be forced to change the expiration time)

Thanks to Stuart for the idea.

Thoughts?




Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.90
diff -u -r1.90 user.c
--- user.c  29 Jan 2012 08:38:54 -  1.90
+++ user.c  11 Sep 2012 13:38:12 -
@@ -100,7 +100,9 @@
F_UID   = 0x0400,
F_USERNAME  = 0x0800,
F_CLASS = 0x1000,
-   F_SETSECGROUP   = 0x4000
+   F_SETSECGROUP   = 0x4000,
+   F_ACCTLOCK  = 0x8000,
+   F_ACCTUNLOCK= 0x1
 };
 
 #define CONFFILE   /etc/usermgmt.conf
@@ -1339,11 +1341,14 @@
struct group*grp;
const char  *homedir;
charbuf[LINE_MAX];
+   charlocked_str[] = -;
+   charshell_len[MaxShellNameLen];
size_t  colonc, loginc;
size_t  cc;
FILE*master;
charnewdir[MaxFileNameLen];
char*colon;
+   char*shell_tmp = NULL;
int len;
int masterfd;
int ptmpfd;
@@ -1359,6 +1364,10 @@
if (!is_local(login_name, _PATH_MASTERPASSWD)) {
errx(EXIT_FAILURE, User `%s' must be a local user, 
login_name);
}
+   if (up != NULL) {
+   if ((up-u_flags  (F_ACCTLOCK | F_ACCTUNLOCK))  (login_name 
== 0))
+   errx(EXIT_FAILURE, (un)locking is not supported for 
the `%s' account, pwp-pw_name);
+   }
/* keep dir name in case we need it for '-m' */
homedir = pwp-pw_dir;
 
@@ -1410,6 +1419,35 @@
pwp-pw_passwd = up-u_password;
}
}
+   if (up-u_flags  F_ACCTLOCK) {
+   if (strncmp(pwp-pw_shell+strlen(pwp-pw_shell) - 1, 
locked_str+strlen(locked_str) - 1, sizeof(locked_str) - 1) == 0) {
+warnx(account '%s' is already locked, 
pwp-pw_name);
+   } else {
+   shell_tmp = malloc(strlen(pwp-pw_shell) + 
sizeof(locked_str));
+   if (shell_tmp == NULL) {
+   (void) close(ptmpfd);
+   pw_abort();
+   errx(EXIT_FAILURE, lock: cannot 
allocate memory);
+   }
+   strlcpy(shell_tmp, pwp-pw_shell, 
sizeof(shell_len));
+   strlcat(shell_tmp, locked_str, 
sizeof(shell_len));
+   pwp-pw_shell = shell_tmp;
+   }
+   }
+   if (up-u_flags  F_ACCTUNLOCK) {
+   if (strncmp(pwp-pw_shell+strlen(pwp-pw_shell) - 1, 
locked_str+strlen(locked_str) - 1, sizeof(locked_str) - 1) != 0) {
+   warnx(account '%s' is not locked, 
pwp-pw_name);
+   } else {
+   shell_tmp = malloc(strlen(pwp-pw_shell) - 
sizeof(locked_str));
+   if (shell_tmp == NULL) {
+   (void) close(ptmpfd);
+   pw_abort();
+   errx(EXIT_FAILURE, unlock: cannot 
allocate memory);
+   }
+   strlcpy(shell_tmp, pwp-pw_shell, 
sizeof(shell_tmp) + 1);
+   pwp-pw_shell = shell_tmp;
+   }
+   }

Re: usermod: lock/unlock local password

2012-09-11 Thread Antoine Jacoutot
On Tue, Sep 11, 2012 at 04:46:57PM +0200, Antoine Jacoutot wrote:
 On Mon, Sep 10, 2012 at 05:01:13PM +0200, Antoine Jacoutot wrote:
  Hi.
  
  This diff adds 2 new options to usermod(8):
  -U to unlock a user's password
  -Z to lock a user's password
  
  In effect locking/unlocking the password means to add a '!' in front of
  the encrypted entry in master.passwd.
  Note that this disable the _password_ not the account of course (you
  could still connect using ssh+key for e.g.).
  
  That said, I have some use for it and would like to be able to have this
  if at all possible.
  Behavior is basically the same as Linux's usermod(8) except that I am
  using -Z for locking the password (-Z is for SElinux in Linux land and
  -L is used instead but we use it ourselves for the login class).
 
 Ok new diff that does something slightly different.
 Instead of putting a '!' in front of the password (which confused people), 
 lock/unlock means appending/removing a dash to the user's login shell.
 While this is non standard behavior (but as I mentionned in a previous mail, 
 usermod(8) is already not standard accross unices) I think it is better 
 because:
 - account is locked, period (no local login, no remote login -- no surprise 
 for tedu ;-) )
 - no values are touched
   (e.g. one could disable an account by using 'usermod -e 1' but when he 
 wants to re-enable the account he'll be forced to change the expiration time)

New diff which also put a '*' in front of the encrypted password; i.e. both pre 
and post-auth become locked (req. by Theo).
With some man page tweak from jmc.



Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.90
diff -u -r1.90 user.c
--- user.c  29 Jan 2012 08:38:54 -  1.90
+++ user.c  11 Sep 2012 16:20:11 -
@@ -100,7 +100,9 @@
F_UID   = 0x0400,
F_USERNAME  = 0x0800,
F_CLASS = 0x1000,
-   F_SETSECGROUP   = 0x4000
+   F_SETSECGROUP   = 0x4000,
+   F_ACCTLOCK  = 0x8000,
+   F_ACCTUNLOCK= 0x1
 };
 
 #define CONFFILE   /etc/usermgmt.conf
@@ -1339,11 +1341,17 @@
struct group*grp;
const char  *homedir;
charbuf[LINE_MAX];
+   characctlock_str[] = -;
+   charpwlock_str[] = *;
+   charpw_len[PasswordLength + 1];
+   charshell_len[MaxShellNameLen];
size_t  colonc, loginc;
size_t  cc;
FILE*master;
charnewdir[MaxFileNameLen];
char*colon;
+   char*pw_tmp = NULL;
+   char*shell_tmp = NULL;
int len;
int masterfd;
int ptmpfd;
@@ -1359,6 +1367,10 @@
if (!is_local(login_name, _PATH_MASTERPASSWD)) {
errx(EXIT_FAILURE, User `%s' must be a local user, 
login_name);
}
+   if (up != NULL) {
+   if ((up-u_flags  (F_ACCTLOCK | F_ACCTUNLOCK))  (pwp-pw_uid 
== 0))
+   errx(EXIT_FAILURE, (un)locking is not supported for 
the `%s' account, pwp-pw_name);
+   }
/* keep dir name in case we need it for '-m' */
homedir = pwp-pw_dir;
 
@@ -1410,6 +1422,48 @@
pwp-pw_passwd = up-u_password;
}
}
+   if (up-u_flags  F_ACCTLOCK) {
+   /* lock the account */
+   if (strncmp(pwp-pw_shell+strlen(pwp-pw_shell) - 1, 
acctlock_str+strlen(acctlock_str) - 1, sizeof(acctlock_str) - 1) != 0) {
+   shell_tmp = malloc(strlen(pwp-pw_shell) + 
sizeof(acctlock_str));
+   if (shell_tmp == NULL) {
+   (void) close(ptmpfd);
+   pw_abort();
+   errx(EXIT_FAILURE, account lock: 
cannot allocate memory);
+   }
+   strlcpy(shell_tmp, pwp-pw_shell, 
sizeof(shell_len));
+   strlcat(shell_tmp, acctlock_str, 
sizeof(shell_len));
+   pwp-pw_shell = shell_tmp;
+   }
+   /* lock the password */
+   if (strncmp(pwp-pw_passwd, pwlock_str, 
sizeof(pwlock_str)-1) != 0) {
+   pw_tmp = malloc(strlen(pwp-pw_passwd) + 
sizeof(pwlock_str));
+   if (pw_tmp == NULL) {
+   (void) close(ptmpfd);
+   pw_abort();
+   errx(EXIT_FAILURE, password lock: 
cannot allocate memory);
+   }
+   strlcpy(pw_tmp, pwlock_str, sizeof(pw_len));
+  

Re: remove mapstore

2012-09-11 Thread Tobias Ulmer
On Sun, Sep 09, 2012 at 01:52:56AM +0200, Tobias Ulmer wrote:
 mapstore looks like an old error handling artifact. No binary change on
 amd64.

Btw, i've been testing this on armish, i386, landisk, socppc, sgi,
sparc, and hppa as part of another diff i'm cooking. This is really just
a noop ;-)



77(A-D)2012-9-12

2012-09-11 Thread 甘孜
base64 encoded Mime section invalid - length (0) was wrong.

[demime 1.01d removed an attachment of type image/pjpeg which had a name of 
Lrw1285.JPG]



fix disable lidsuspend on shutdown by init(8)

2012-09-11 Thread Alexander Hall
This pulls in machine/cpu.h so we can see CPU_LIDSUSPEND if it's there.
Also fix the resulting compilation errors now that the code is actually
used.

Tested on my X61s/amd64, where shutting down using the power button now
behaves like halt -p in that it won't suspend while shutting down if I
close the lid.

OK?

On a sidenote, why is the shutdown code duplicated between init and
reboot (a.k.a. halt)? Could we just as well make halt() send SIGUSR2
to init, like acpi does?

/Alexander

Index: init.c
===
RCS file: /data/openbsd/cvs/src/sbin/init/init.c,v
retrieving revision 1.46
diff -u -p -r1.46 init.c
--- init.c  6 Apr 2012 17:25:00 -   1.46
+++ init.c  11 Sep 2012 20:43:20 -
@@ -37,6 +37,7 @@
 #include sys/sysctl.h
 #include sys/wait.h
 #include sys/reboot.h
+#include machine/cpu.h
 
 #include db.h
 #include err.h
@@ -1313,7 +1314,7 @@ nice_death(void)
static const int death_sigs[3] = { SIGHUP, SIGTERM, SIGKILL };
int status;
 
-#if CPU_LIDSUSPEND
+#ifdef CPU_LIDSUSPEND
int lidsuspend_mib[] = {CTL_MACHDEP, CPU_LIDSUSPEND};
int dontsuspend = 0;
 
@@ -1321,7 +1322,6 @@ nice_death(void)
(sysctl(lidsuspend_mib, 2, NULL, NULL, dontsuspend,
sizeof(dontsuspend))  0))
warning(cannot disable lid suspend);
-   }
 #endif
 
for (sp = sessions; sp; sp = sp-se_next) {



Make install(1) not delete files when installing to same directory

2012-09-11 Thread Jeremy Evans
Currently, install(1) deletes files when you are installing them to the
same directory, if you only specify the directory name and not the full
path:

  $ echo foo  foo; install foo .; cat foo
  install: ./foo: Bad address
  cat: foo: No such file or directory

This goes against the manual page, which states: The install utility
attempts to prevent moving a file onto itself.

The check for the same inode number is only done when the full path is
given:

  $ echo foo  foo; install foo ./foo; cat foo
  install: foo and ./foo are the same file
  foo

The diff below attempts to handle the situation correctly if only the
directory name is given:

  $ echo foo  foo; install foo .; cat foo
  install: foo and ./foo are the same file
  foo

I'm not sure if the approach I'm using in the diff is correct. If a
directory name is given, I'm checking the inode for that directory
against the directory of the source, and exiting with an error if
they are the same. Would it be better to check if a file with the same
base name exists in the destination directory, and then check the inode
of that file against the file name?

If multiple from files are given, this will exit without processing all
of the files.  Is it better to just warn for each and change the exit
code at the end, so that all files are processed?  I can do that, but
I'm not sure which behavior is actually desired.  I think either
behavior is better than the current behavior of deleting the file.

This fixes an issue that causes the databases/ruby-ldap port to not
build if it loses a race.

Jeremy

Index: xinstall.c
===
RCS file: /cvs/src/usr.bin/xinstall/xinstall.c,v
retrieving revision 1.51
diff -u -p -r1.51 xinstall.c
--- xinstall.c  11 Apr 2012 14:19:35 -  1.51
+++ xinstall.c  11 Sep 2012 23:09:03 -
@@ -40,6 +40,7 @@
 #include errno.h
 #include fcntl.h
 #include grp.h
+#include libgen.h
 #include paths.h
 #include pwd.h
 #include stdio.h
@@ -167,8 +168,14 @@ main(int argc, char *argv[])
 
no_target = stat(to_name = argv[argc - 1], to_sb);
if (!no_target  S_ISDIR(to_sb.st_mode)) {
-   for (; *argv != to_name; ++argv)
+   for (; *argv != to_name; ++argv) {
+   if (stat(dirname(*argv), from_sb))
+   err(EX_OSERR, %s, dirname(*argv));
+   if (to_sb.st_dev == from_sb.st_dev 
+   to_sb.st_ino == from_sb.st_ino)
+   errx(EX_USAGE, %s and %s/%s are the same 
file, *argv, to_name, basename(*argv));
install(*argv, to_name, fset, iflags | DIRECTORY);
+   }
exit(EX_OK);
/* NOTREACHED */
}