Re: J-Pilot Permissions Vulnerability

[Scott Nelson <SBNelson () THERMEON COM>]

I really like the "private user group" (the user's default group is one that
only they are a member of) concept (except for the fact that it eats up
groups like mad).  That way, I can leave the umask set to 07 or 027.  Then
you have directories that have the setgid bit set so that when I create
private files (my home directory) nobody can read them, but when I create
some group oriented files (in those directories), anyone in that group can
read them.  The only time I need to fiddle with umask and/or permissions is
when creating a file that is world readable, or into directories that are
not for specific groups.

> -----Original Message-----
> From: Robert Bihlmeyer [SMTP:robbe () ORCUS PRIV AT]
> Sent: Tuesday, December 19, 2000 3:26 AM
> To:   BUGTRAQ () SECURITYFOCUS COM
> Subject:      Re: J-Pilot Permissions Vulnerability
>
> Judd Montgomery <judd () ENGINEER COM> writes:
>
> > J-Pilot has always used the pre set umask when creating directories and
> > files, therefore I have never considered this to be a security risk.  It
> > is up to the system administrator or the user to set the umask to
> > his/her liking.
>
> I think the umask concept is lacking here. I need at least two general
> levels of modes: I'm perfectly happy with other users reading
> (executing) my shell scripts, source code, etc. - so I generally leave
> the umask somewhere near 022.
>
> OTOH, there's definitely data that I would like to keep private from
> everybody, or everybody outside my group: private notes, financial
> data, my mail, bookmarks, and so on.
>
> The only way one can reach this goal with umask is with wrapper
> scripts (for example, gnucash could be wrapped by "(umask 077;
> gnucash.real)"). For notes, I'd have to have two instances of Emacs
> (public and private) running. Messy.
>
> The alternative is to give more responsibility to applications. I
> think a good approximation for J-Pilot would be to OR the umask with
> 044, iff there are any private records present. Other apps that
> sometimes save private information could perhaps support a "private
> mode" (i.e. an editor could offer a command to later save a buffer
> with private umask).
>
> Of course, ALL apps should preserve the mode of existing files unless
> told otherwise ...
>
> --
> Robbe