Anthony Towns aj@azure.humbug.org.au writes:
On Sun, Nov 10, 2002 at 11:26:31AM -0800, Thomas Bushnell, BSG wrote:
/usr/share is not appropriate for that, as it is the OS's playground
(and I can't see any use for the OS installing secrets there).
For site-specific secrets
On Sun, Nov 10, 2002 at 11:26:31AM -0800, Thomas Bushnell, BSG wrote:
/usr/share is not appropriate for that, as it is the OS's playground
(and I can't see any use for the OS installing secrets there).
For site-specific secrets /usr/local/share is a better choice.
root users is not somehow
On 10 Nov 2002, Thomas Bushnell, BSG wrote:
One such thing that can be shared, but which should also be secret, is
a nethack bones level file. That shouldn't go in /var, because it
*should* be shared normally by a group of cooperating machines. (The
whole point of nethack bones files is
On Sun, Nov 10, 2002 at 10:02:42PM -0800, Thomas Bushnell, BSG wrote:
One such thing that can be shared, but which should also be secret, is
a nethack bones level file. That shouldn't go in /var, because it
*should* be shared normally by a group of cooperating machines.
Portions of /var are
Matthew Palmer [EMAIL PROTECTED] writes:
While not being a nethack afficionado, I admin for people who are. Aren't
bones levels variable, and hence should not be placed in /usr anyway?
Certainly, I know that bones levels are created on the nethack machine, and
that machine's /usr is mounted
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
There is no rule that /usr can always be safely mounted read-only in
FHS or the GNU Coding Standards. If it works for you, great, but by
no means would I advise relying on it.
Blech, I was wrong here, for which I apologize. The FHS does
Anthony Towns aj@azure.humbug.org.au writes:
If you want to share nethack bones files, you put them in /var/games/nethack,
or similar, then share it.
The problem with this strategy is that it requires administrators to
keep track of which packages can share which directories, and this is
in
On Sun, Nov 10, 2002 at 11:02:51PM -0800, Thomas Bushnell, BSG wrote:
Still, I'm loath to create extra rules that we don't need. In
general, yes, *every* file should be readable, and it's appropriate to
file bug reports for the Debian packages which needlessly prevent
files from being
Anthony Towns aj@azure.humbug.org.au writes:
On Sun, Nov 10, 2002 at 11:02:51PM -0800, Thomas Bushnell, BSG wrote:
Still, I'm loath to create extra rules that we don't need. In
general, yes, *every* file should be readable, and it's appropriate to
file bug reports for the Debian packages
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
This is incorrect. /usr/share is intended to be shared between
cooperating systems, but cooperating systems' root users might well
have secrets that they want to conveniently share.
/usr/share is not appropriate for that, as it is the OS's
Robert Bihlmeyer [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
This is incorrect. /usr/share is intended to be shared between
cooperating systems, but cooperating systems' root users might well
have secrets that they want to conveniently share.
/usr/share
Matthew Swift [EMAIL PROTECTED] writes:
Because files in /usr/share are expected to be shared, they should all
be world-readable.
This is incorrect. /usr/share is intended to be shared between
cooperating systems, but cooperating systems' root users might well
have secrets that they want to
On Sun, Nov 03, 2002 at 12:47:27PM +0700, Robert Lemmen wrote:
On Sat, Nov 02, 2002 at 02:26:24PM -0500, Branden Robinson wrote:
Also, make a policy proposal that all files in /usr/share be
world-readable on Debian systems.
and create an according lintian check!
The non-standard-file-perm
Matthew == Matthew Swift [EMAIL PROTECTED] writes:
[...]
Matthew On my system today, the following files in /usr/share are
Matthew not world-readable:
Matthew % find /usr/share -not -perm -o=r
Matthew /usr/share/doc/squid/examples/squid.conf
Matthew
14 matches
Mail list logo
