Re: A very 'trivial' question about /root
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.
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
Unices.
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
AFAIR.
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
8.0/8.1/9.0/9.1)
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.
Cheers,
Julian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
MAC and Xorg on FBSD 9.1-p4 (re-sending)
Hi all, as you can see from the footer I've already posted this on the list trustedbsd-disc...@freebsd.org but because that one seems to be dead to me I apologise if I'm trying to get some hint here. Briefly, I'm trying to run X on my FreeBSD 9.1 with the following MAC modules enabled: mac_biba mac_mls mac_seeotheruids mac_partition I'm still actually in the learning process of this very granular but complex security system but I'm learning fast as I found it very interesting. Unfortunately when it comes to X it seems to be more complicated. I cannot run it not even as root. I get: .. Unable to map MMIO aperture. Permission denied (13) Memory map the MMIO region failed .. until the timeout and back to prompt. I get the same error with root which is the default login class and on an ad-hoc restricted user. As soon as I disable the modules everything works well. I know this is a very brief description but it should be enough for now to know if this is a known issue and/or the X system is known as NOT WORKING/HAVING PROBLEMS with MAC. And as MAC on FreeBSD is dark matter (googling is basically useless if not for basic conf.) any hint would be highly appreciated. Thanks a lot. ___ trustedbsd-disc...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/trustedbsd-discuss To unsubscribe, send any mail to trustedbsd-discuss-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: A very 'trivial' question about /root
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 Unices. 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 AFAIR. 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 8.0/8.1/9.0/9.1) 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. :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
MAC and Xorg on FBSD 9.1-p4
Hi all, as you can see from the footer I've already posted this on the list trustedbsd-disc...@freebsd.org but because that one seems to be dead to me I apologise if I'm trying to get some hint here. Briefly, I'm trying to run X on my FreeBSD 9.1 with the following MAC modules enabled: mac_biba mac_mls mac_seeotheruids mac_partition I'm still actually in the learning process of this very granular but complex security system but I'm learning fast as I found it very interesting. Unfortunately when it comes to X it seems to be more complicated. I cannot run it not even as root. I get: .. Unable to map MMIO aperture. Permission denied (13) Memory map the MMIO region failed .. until the timeout and back to prompt. I get the same error with root which is the default login class and on an ad-hoc restricted user. As soon as I disable the modules everything works well. I know this is a very brief description but it should be enough for now to know if this is a known issue and/or the X system is known as NOT WORKING/HAVING PROBLEMS with MAC. And as MAC on FreeBSD is dark matter (googling is basically useless if not for basic conf.) any hint would be highly appreciated. Thanks a lot. ___ trustedbsd-disc...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/trustedbsd-discuss To unsubscribe, send any mail to trustedbsd-discuss-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
A very 'trivial' question about /root
This is a very 'trivial' question but it's bugging me since quite a while now so I gotta ask. 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 8.0/8.1/9.0/9.1) Thanks in advance. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: just a curiosity about auth.conf
I haven't installed 9.1 yet but good to know. Thanks. On Thu, 2013-01-03 at 08:26 +, Arthur Chance wrote: On 01/01/13 12:33, ASV wrote: Good afternoon and happy new year to everybody. I'm just curious about auth.conf. According to the detailed release notes (http://www.freebsd.org/releases/9.1R/relnotes-detailed.html): auth.conf(5) has been removed because it was deprecated years ago.[r238481] but according to the man pages online AUTH.CONF(5) of FBSD9.0-RELEASE: auth.conf contains various attributes important to the authentication code, most notably crypt(3) for the time being. This documentation will be updated as the /etc/auth.conf file, which is very new, evolves.. How can something deprecated years ago being new and evolving quickly enough to require further doc updates? Am I missing something? :) Looks like the man page hasn't been updated in a while. If you're not yet on 9.1, and look at auth.conf itself it says in the header comments # Configure some authentication-related defaults. This file is being # gradually subsumed by user class and PAM configuration. I.e. it is/was an old way of doing things that has been replaced by newer mechanisms. Personally I'm glad to see the team clearing out the cruft. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Newbie question about freebsd-update: single user mode is not needed anymore?
Well, I understand your concern. I've been using the freebsd-update method since several years now and mostly remotely. I've never encounter a problem. I haven't recompiled everything many times as I didn't really found a tangible advantage in this method but I've never thought about this. I believe some developer around here can provide you a neat explanation about that (which is going to be interesting to know). Strictly about your concern I believe whatever way you use for your upgrade you CANNOT be 100% sure that your upgrade will go smoothly and things like loosing control of your remote box will not happen. Even though jumping from close releases 9.0 = 9.1 is a low risk upgrade, a console access to your remote server (via terminal server/KVM/other) is imperative in these cases to avoid the worst. On Mon, 2012-12-31 at 16:50 +0100, Jose Garcia Juanino wrote: El lunes 31 de diciembre a las 16:27:44 CET, ASV escribió: Hi Jose, with the freebsd-update method you don't need to pass through the make installworld as it's a binary patch/upgrade system. Using freebsd-update upgrade -r 9.1-RELEASE for example allows you to get your system patched directly without recompiling the kernel and the userland but getting binary patches from the repo and applying these directly on your system. Check the following page for a more detailed explanation and be aware that upgrading your ports/packages is required every time you upgrade your kernel to a major version (which would be your case). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Happy new year. Thanks for your response. The freebsd-update upgrade method is: 1- freebsd-update install # will install a new kernel and modules 2- reboot in multi user 3- freebsd-update install # will install new userland 4- reboot in multi user The src upgrade method is: 1- make installkernel # will install a new kernel 2- reboot in single user 3- make installworld # will install a new userland 4- reboot in multiuser I think that the third step is essentially the same in both methods: it will install a new userland. But the second one require to be ran in single user, and the first one does not. Why? My unique concern is that step 2 in freebsd-update method goes smootly: it will boot kernel in 9.1-RELEASE but userland in 9.0-RELEASE. If the system hangs giving up the net or other essential service, I will not be able to reach the computer via ssh. Regards ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
just a curiosity about auth.conf
Good afternoon and happy new year to everybody. I'm just curious about auth.conf. According to the detailed release notes (http://www.freebsd.org/releases/9.1R/relnotes-detailed.html): auth.conf(5) has been removed because it was deprecated years ago.[r238481] but according to the man pages online AUTH.CONF(5) of FBSD9.0-RELEASE: auth.conf contains various attributes important to the authentication code, most notably crypt(3) for the time being. This documentation will be updated as the /etc/auth.conf file, which is very new, evolves.. How can something deprecated years ago being new and evolving quickly enough to require further doc updates? Am I missing something? :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Newbie question about freebsd-update: single user mode is not needed anymore?
For some reason my email hasn't apparently been delivered so I'm re-sending it. From: ASV a...@inhio.eu To: Jose Garcia Juanino jjuan...@gmail.com Cc: freebsd-questions@freebsd.org Subject:Re: Newbie question about freebsd-update: single user mode is not needed anymore? Date: Mon, 31 Dec 2012 17:19:19 +0100| Well, I understand your concern. I've been using the freebsd-update method since several years now and mostly remotely. I've never encounter a problem. I haven't recompiled everything many times as I didn't really found a tangible advantage in this method but I've never thought about this. I believe some developer around here can provide you a neat explanation about that (which is going to be interesting to know). Strictly about your concern I believe whatever way you use for your upgrade you CANNOT be 100% sure that your upgrade will go smoothly and things like loosing control of your remote box will not happen. Even though jumping from close releases 9.0 = 9.1 is a low risk upgrade, a console access to your remote server (via terminal server/KVM/other) is imperative in these cases to avoid the worst. On Mon, 2012-12-31 at 16:50 +0100, Jose Garcia Juanino wrote: El lunes 31 de diciembre a las 16:27:44 CET, ASV escribió: Hi Jose, with the freebsd-update method you don't need to pass through the make installworld as it's a binary patch/upgrade system. Using freebsd-update upgrade -r 9.1-RELEASE for example allows you to get your system patched directly without recompiling the kernel and the userland but getting binary patches from the repo and applying these directly on your system. Check the following page for a more detailed explanation and be aware that upgrading your ports/packages is required every time you upgrade your kernel to a major version (which would be your case). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Happy new year. Thanks for your response. The freebsd-update upgrade method is: 1- freebsd-update install # will install a new kernel and modules 2- reboot in multi user 3- freebsd-update install # will install new userland 4- reboot in multi user The src upgrade method is: 1- make installkernel # will install a new kernel 2- reboot in single user 3- make installworld # will install a new userland 4- reboot in multiuser I think that the third step is essentially the same in both methods: it will install a new userland. But the second one require to be ran in single user, and the first one does not. Why? My unique concern is that step 2 in freebsd-update method goes smootly: it will boot kernel in 9.1-RELEASE but userland in 9.0-RELEASE. If the system hangs giving up the net or other essential service, I will not be able to reach the computer via ssh. Regards ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Newbie question about freebsd-update: single user mode is not needed anymore?
Hi Jose, with the freebsd-update method you don't need to pass through the make installworld as it's a binary patch/upgrade system. Using freebsd-update upgrade -r 9.1-RELEASE for example allows you to get your system patched directly without recompiling the kernel and the userland but getting binary patches from the repo and applying these directly on your system. Check the following page for a more detailed explanation and be aware that upgrading your ports/packages is required every time you upgrade your kernel to a major version (which would be your case). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Happy new year. On Mon, 2012-12-31 at 13:13 +0100, Jose Garcia Juanino wrote: Hi, I am planning to upgrade from FreeBSD 9.0-RELEASE to FreeBSD-9.1-RELEASE. With upgrade source method, it is always needed to do the make installworld step in single user mode. But it seems to be that single user is not required with freebsd-update method, in the second freebsd-update install. Someone could explain the reason? Am I misunderstanding something? Can I run the upgrade enterely by mean a ssh connection in a safe way, or will I need a serial console? Best regards, and excuse my poor english. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
