Make install(1) not delete files when installing to same directory
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
#include
#include
+#include
#include
#include
#include
@@ -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 */
}
fix disable lidsuspend on shutdown by init(8)
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
#include
#include
+#include
#include
#include
@@ -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) {
77(A-D)2012-9-12
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]
Re: remove mapstore
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 ;-)
Re: usermod: lock/unlock local password
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");
+ }
+
Re: usermod: lock/unlock local password
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;
+
Coaching y Multihabilidades de Supervisión
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
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
Re: usermod: lock/unlock local password
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
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
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
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
On Tue, Sep 11, 2012 at 10:23:13AM +0300, Eugene Yunak wrote: > On 11 September 2012 09:37, Antoine Jacoutot wrote: > > On Tue, Sep 11, 2012 at 09:33:56AM +0300, Eugene Yunak wrote: > >> On 10 September 2012 18:01, 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). > >> > > >> > 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
On 11 September 2012 09:37, Antoine Jacoutot wrote: > On Tue, Sep 11, 2012 at 09:33:56AM +0300, Eugene Yunak wrote: >> On 10 September 2012 18:01, 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). >> > >> > 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
