On Fri, 28 Jun 2013, ASV wrote:

Hi Julian,
you played Devil's advocate well actually as I don't know which idea
would be more audacious, letting httpd access files from your root dir
or exporting /root via nfs. :)
Both of them sound more like a lab scenario than a real one.

A diskless FreeBSD will use an NFS-mounted /root. See:


So it is more than a theoretical possibility. I would also add that putting stricter permissions on perfectly public information may not
lead to improved security, if it leads to programs and daemons that
would otherwise run as nobody having to run with root priviledges.

daniel feenberg

I understand that launching a "chmod 700 /root" it's a matter of
something between 1 and 3 seconds. I do also understand that I had /root
closed for long time and never had the need to set permissions back
loose and this triggered my point.
Why is it that open? :)

On Fri, 2013-06-28 at 01:47 +0200, Julian H. Stacey wrote:
Hi, Reference:
From:           ASV <a...@inhio.eu>
Date:           Thu, 27 Jun 2013 21:39:20 +0200

ASV wrote:
Thanks for your reply Polytropon,

I'm using FreeBSD since few years already and I'm kind of aware of the
"dynamics" related to permissions, many of them are common to many
I agree that the installer doesn't put anything secret but as a home dir
for the root user it's highly likely that something not intended to be
publicly readable will end up there soon after the installation.
Which IMHO it's true also for any other user homedir which gets created
by default using a pretty relaxed umask 022, but that seems to be the
default on probably any other UNIX like system I've put my hands on

Don't get me wrong, since I use FreeBSD I'm just in love with it. Mine
is just a concern about these permission defaults which look to me a bit
too relaxed and cannot find yet a reason why not to restrict it.
After all I believe having good default settings may make the difference
in some circumstances and/or save time.

On Thu, 2013-06-27 at 04:58 +0200, Polytropon wrote:
On Wed, 26 Jun 2013 23:34:41 +0200, ASV wrote:
There's any reason (and should be a fairly good one) why the /root
directory permissions by default are set to 755 (for sure on releases

This is the default permission for user directories, as root
is considered a user in this (special) case, and /root is its
home directory. The installer does not put anything "secret"
in there, but _you_ might, so there should be no issue changing
it to a more restricted access permission.

Hint: When a directory is r-x for "other", then it will be
indexed by the locate periodic job, so users could use the
locate command (and also find) to look what's in there. If
this is not desired, change to rwx/---/---, or rwx/r-x/---
if you want to allow (trusted) users of the "wheel" group
to read and execute stuff from that directory (maybe homemade
admin scripts in /root/bin that should not be "public").

There are few things that touch /root content. System updating
might be one of them, but as it is typically run as root (and
even in SUM), restrictive permissions above the default are
no problem.

To summarize the answer for your question: It's just the default. :-)

I'll play Devil's advocate for a moment ;-)

  One reason not to tighten ~root is because one might want
  ~root/httpuserfile to be readable by httpd to access the crypted
  passwords of locked web page. ... ;-)

No not really, that's perverted, I wouldn't reccomend an
http://localhost/~root/ regardless of password locked pages or not.

But it shows how lateral head scratching might be
appropriate before removing read perms on ~root/ .

{ A bit like wrong ownership on / can surprisingly kill AMD NFS
access } ... some unexpected constraints can take some thinking
through, It might be quickest for a number of us to just try chmod
700 ~root for a while & see if we get trouble.


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to