headers
S.P.Zeidler | 4 Apr 2012 22:57
Picon

duplicate uid warning in daily security check

Hi,

I have a few intentional duplicate UIDs, and the daily warning is
annoying me. Proposed fix: make a configurable list of user ids that
aren't considered for the purpose of duplicate uid detection, and adjust
/etc/security to fit.

This gives us a new entry in defaults listing "toor":

RCS file: /cvsroot/src/etc/defaults/security.conf,v
retrieving revision 1.23
diff -u -u -r1.23 security.conf
--- defaults/security.conf      5 Feb 2010 16:29:02 -0000       1.23
+++ defaults/security.conf      4 Apr 2012 20:46:16 -0000
 <at>  <at>  -41,6 +41,7  <at>  <at> 

 check_passwd_nowarn_shells="/sbin/nologin"
 check_passwd_nowarn_users=""
+check_passwd_permit_dups="toor"
 check_passwd_permit_star=NO
 check_passwd_permit_nonalpha=NO
 max_loginlen=16

and:

RCS file: /cvsroot/src/etc/security,v
retrieving revision 1.110
diff -u -u -r1.110 security
--- security    2 Mar 2011 17:00:28 -0000       1.110
+++ security    4 Apr 2012 20:46:16 -0000
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christos Zoulas | 5 Apr 2012 05:05

Re: duplicate uid warning in daily security check

In article <20120404205716.GO7066 <at> serpens.de>,
S.P.Zeidler <spz <at> serpens.de> wrote:
>Hi,
>
>I have a few intentional duplicate UIDs, and the daily warning is
>annoying me. Proposed fix: make a configurable list of user ids that
>aren't considered for the purpose of duplicate uid detection, and adjust
>/etc/security to fit.
>
>This gives us a new entry in defaults listing "toor":
>
>RCS file: /cvsroot/src/etc/defaults/security.conf,v
>retrieving revision 1.23
>diff -u -u -r1.23 security.conf
>--- defaults/security.conf      5 Feb 2010 16:29:02 -0000       1.23
>+++ defaults/security.conf      4 Apr 2012 20:46:16 -0000
> <at>  <at>  -41,6 +41,7  <at>  <at> 
> 
> check_passwd_nowarn_shells="/sbin/nologin"
> check_passwd_nowarn_users=""
>+check_passwd_permit_dups="toor"
> check_passwd_permit_star=NO
> check_passwd_permit_nonalpha=NO
> max_loginlen=16
>
>and:
>
>RCS file: /cvsroot/src/etc/security,v
>retrieving revision 1.110
>diff -u -u -r1.110 security
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Holland | 9 Apr 2012 06:44
Picon

Re: duplicate uid warning in daily security check

On Wed, Apr 04, 2012 at 10:57:17PM +0200, S.P.Zeidler wrote:
 > I have a few intentional duplicate UIDs, and the daily warning is
 > annoying me. Proposed fix: make a configurable list of user ids that
 > aren't considered for the purpose of duplicate uid detection, and adjust
 > /etc/security to fit.
 > 
 > This gives us a new entry in defaults listing "toor":
 > [...]

one quibble: maybe the name of the variable should be
"check_passwd_expected_dups"?

Otherwise looks fine to me.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
Tamas Toth | 10 Apr 2012 11:41
Picon
Favicon

chfs support in makefs

Hi,

I added chfs support to makefs. It's a bit ugly, because I had to copy  
some parts of sys/vnode.h to chfs/mkfs_chfs.c. (Tools can't be compiled  
with build.sh if I include the sys/vnode.h.)

Does anyone have a better solution to this problem and/or comments on the  
code or can I commit it?

ttoth
Attachment (mkfs.chfs.diff): application/octet-stream, 29 KiB
Permalink | Reply | 18 comments |
headers
Martin Husemann | 10 Apr 2012 13:13
Picon

Re: chfs support in makefs

On Tue, Apr 10, 2012 at 11:41:11AM +0200, Tamas Toth wrote:
> I added chfs support to makefs. It's a bit ugly, because I had to copy  
> some parts of sys/vnode.h to chfs/mkfs_chfs.c. (Tools can't be compiled  
> with build.sh if I include the sys/vnode.h.)

I wonder if we should run a second "late tools" build for tools only needed
to prepare installation images and similar, which then can rely on the 
installed target headers.

Duplicating this definitions sounds dangerous.

Martin
Permalink | Reply | 0 comments |
headers
Joerg Sonnenberger | 10 Apr 2012 15:20
Picon

Re: chfs support in makefs

On Tue, Apr 10, 2012 at 11:41:11AM +0200, Tamas Toth wrote:
> I added chfs support to makefs. It's a bit ugly, because I had to
> copy some parts of sys/vnode.h to chfs/mkfs_chfs.c. (Tools can't be
> compiled with build.sh if I include the sys/vnode.h.)

Create a local copy of vnode.h in the Makefile and include that with
#include "vnode.h"  for the host program case?

Joerg
Permalink | Reply | 1 comment |
headers
Alan Barrett | 10 Apr 2012 15:56
Gravatar

Re: chfs support in makefs

On Tue, 10 Apr 2012, Tamas Toth wrote:
>I added chfs support to makefs. It's a bit ugly, because I had to copy 
>some parts of sys/vnode.h to chfs/mkfs_chfs.c. (Tools can't be 
>compiled with build.sh if I include the sys/vnode.h.)

What goes wrong when you try to build tools?

--apb (Alan Barrett)
Permalink | Reply | 1 comment |
headers
Chuck Silvers | 10 Apr 2012 16:02
Favicon

Re: chfs support in makefs

On Tue, Apr 10, 2012 at 11:41:11AM +0200, Tamas Toth wrote:
> Hi,
> 
> I added chfs support to makefs. It's a bit ugly, because I had to
> copy some parts of sys/vnode.h to chfs/mkfs_chfs.c. (Tools can't be
> compiled with build.sh if I include the sys/vnode.h.)
> 
> Does anyone have a better solution to this problem and/or comments
> on the code or can I commit it?

sys/vnode.h should not be used to define the on-disk format of any file system.
everything it contains is for in-core use only.  chfs should provide its own
definition for anything that it wants to store on disk.

-Chuck
Permalink | Reply | 1 comment |
headers
Tamas Toth | 10 Apr 2012 16:24
Picon
Favicon

Re: chfs support in makefs

> What goes wrong when you try to build tools?

sys/vnode.h include some uvm related files and they need vaddr_t and  
vsize_t types. They should come from machine/types.h, but only if  
_NETBSD_SOURCE is defined.

I think that sys/vnode.h shouldn't be included in a userspace program  
anyway.
Permalink | Reply | 0 comments |
headers
Tamas Toth | 10 Apr 2012 16:33
Picon
Favicon

Re: chfs support in makefs


> Create a local copy of vnode.h in the Makefile and include that with
> #include "vnode.h"  for the host program case?

I think this solution would be as ugly as the current code.
Permalink | Reply | 0 comments |

Gmane