resolvconf overwriting /etc/resolv.conf
Hi, I run bind on a LAN, with some LAN-only (sub)domains. On the LAN is also a DSL modem/router that advertises ipv6 addresses. So far so good. However, since I upgraded the server from 8-STABLE to 9.1-PRERELEASE, the /etc/resolv.conf gets overwritten by the resolvconf script, with an ipv6 nameserver (presumably the router, haven't checked). This is not what I want. Now I see that you can prepend nameservers through /etc/resolvconf.conf, but what I really want is for resolvconf to leave my /etc/resolv.conf alone. Is there any way to disable the script (apart from deleting it)? thanks, Ruben ___ 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
Obsolete Shared Libraries?
9.1 RC3 (started out as 9.0 RELEASE) Over time, as ports have been upgraded, I seem to have accumulated a number of obsolete shared libraries - a recent example being /usr/local/ lib/libpcre.so.1, which appears no longer to be linked in by anything, having been replaced by libpcre.so.3. Is there a convenient and safe utility to clean out this detritus? I'm not trying to save disk space or anything; it's just a matter of tidiness. ___ 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: Obsolete Shared Libraries?
On Tue, 18 Dec 2012 12:40:39 + (UTC) Walter Hurry walterhu...@gmail.com wrote: 9.1 RC3 (started out as 9.0 RELEASE) Over time, as ports have been upgraded, I seem to have accumulated a number of obsolete shared libraries - a recent example being /usr/local/ lib/libpcre.so.1, which appears no longer to be linked in by anything, having been replaced by libpcre.so.3. Is there a convenient and safe utility to clean out this detritus? I'm not trying to save disk space or anything; it's just a matter of tidiness. portsclean - it will also tidy up distfiles, packages and work areas. -- Steve O'Hara-Smith st...@sohara.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: i386 vs. amd64
On 12/18/12 00:13, Erich Dollansky wrote: Hi, wasn't the same question here a few days ago? On Tue, 18 Dec 2012 00:16:36 -0500 Aryeh Friedman aryeh.fried...@gmail.com wrote: Ever since 8.X (my system is now 9.1-RC3 [done via csup]) been using i386 with the following main ports: Let me chime in where Erich couldn't answer as I recently made the switch to amd64 myself. x11-wm/xfce4 yes. www/firefox Yes. www/linux-f10-flashplugin11 Yes editors/libreoffice Yes. www/tomcat-7 www/apace22 Typo? Apache 2.2 runs. devel/aegis (I am the maintainer) devel/fhist devel/cook java/openjdk6 Yes snip So I have the following questions: 1. Will all the above ports (and their dependencies) work on amd64? I gave you the answer if I knew one. I general, I do not have problems which are linked to 32 or 64 bits. I've had no problems either, and I am in the middle of a devel/pcre rebuilding (over 200 ports). 2. Is there any way to do a in place switch to amd64 or do I need to rebuild the system from the ground up? To my knowledge, it is still a fresh installation. Just download an image and start from there. I think the handbook gives directions for an in-place switch, but it (and many, many others) suggest a fresh install, which is what I went with (I had other reasons as well). 3. In general is amd64 now as capable of handling ports and such as well as i386 does? I saw that some ports I used to use on i386 went 100% smooth on amd64. I believe that this has improved even further. Just make the jump. snip I agree, I've had no problems related to the arch since I switched and would 100% recommend it for anyone considering it. -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.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: FreeBSD as VMWare guest / disk resizing
You'll of course need to boot from another medium to do this. That's my main question - can a larger disk be detected *without* a reboot. On FreeBSD instances running within VMWare I have been able to add new disks without a reboot but, as I described below, have not found a way to get the operating system to detect a larger *existing* disk without a reboot. VMWare allows you to resize a disk on the fly. Obviously I'm only interested in the grow the disk scenario :-) I'm beginning to think a reboot is necessary, which is surprising! On Dec 17, 2012, at 4:15 PM, Luke Bakken wrote: Hello everyone - I'm looking for a way to get FreeBSD 8 / 9 to detect that an already existing disk has grown. I have FreeBSD running as a guest within vSphere ESX 5. Here is the output of camcontrol showing how the disks are detected within the OS: [root@QA1HWFBSD83201 ~]# camcontrol inquiry da0 pass0: VMware Virtual disk 1.0 Fixed Direct Access SCSI-2 device pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Command Queueing Enabled In the VM settings I can increase the disk size but I can't seem to find the right command within FreeBSD to force it to detect the new, larger size without a reboot. 'camcontrol rescan all' works great to detect a new drive but doesn't detect a larger disk. Within a Linux distribution like Debian, the following command will detect the larger drive: echo 1 /sys/class/scsi_device/0:0:0:0/device/rescan I apologize if this has been answered in the archives or online but I just haven't been able to get a definitive answer if this is possible, and how. Thanks so much in advance, Luke ___ 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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: FreeBSD as VMWare guest / disk resizing
On Tue, 18 Dec 2012, Luke Bakken wrote: You'll of course need to boot from another medium to do this. That's my main question - can a larger disk be detected *without* a reboot. On FreeBSD instances running within VMWare I have been able to add new disks without a reboot but, as I described below, have not found a way to get the operating system to detect a larger *existing* disk without a reboot. VMWare allows you to resize a disk on the fly. Obviously I'm only interested in the grow the disk scenario :-) Force a GEOM retaste? # true /dev/ada0 ___ 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: FreeBSD as VMWare guest / disk resizing
On Dec 18, 2012, at 6:35 AM, Luke Bakken wrote: You'll of course need to boot from another medium to do this. That's my main question - can a larger disk be detected *without* a reboot. On FreeBSD instances running within VMWare I have been able to add new disks without a reboot but, as I described below, have not found a way to get the operating system to detect a larger *existing* disk without a reboot. VMWare allows you to resize a disk on the fly. Obviously I'm only interested in the grow the disk scenario :-) I'm beginning to think a reboot is necessary, which is surprising! Live resize (without reboot even) is something being worked on for the future 10.x series. -- Devin On Dec 17, 2012, at 4:15 PM, Luke Bakken wrote: Hello everyone - I'm looking for a way to get FreeBSD 8 / 9 to detect that an already existing disk has grown. I have FreeBSD running as a guest within vSphere ESX 5. Here is the output of camcontrol showing how the disks are detected within the OS: [root@QA1HWFBSD83201 ~]# camcontrol inquiry da0 pass0: VMware Virtual disk 1.0 Fixed Direct Access SCSI-2 device pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Command Queueing Enabled In the VM settings I can increase the disk size but I can't seem to find the right command within FreeBSD to force it to detect the new, larger size without a reboot. 'camcontrol rescan all' works great to detect a new drive but doesn't detect a larger disk. Within a Linux distribution like Debian, the following command will detect the larger drive: echo 1 /sys/class/scsi_device/0:0:0:0/device/rescan I apologize if this has been answered in the archives or online but I just haven't been able to get a definitive answer if this is possible, and how. Thanks so much in advance, Luke ___ 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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
mfsroot starts sysinstall how?
Hi all, For anyone interested, I posted a blog with regards to how sysinstall is run from mfsroot. URL is http://blog.hostileadmin.com/2012/12/18/mfsroot-starts-sysinstall-how/ -- Take care Rick Miller ___ 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: FreeBSD as VMWare guest / disk resizing
On 18 December 2012 15:27, Devin Teske devin.te...@fisglobal.com wrote: On Dec 18, 2012, at 6:35 AM, Luke Bakken wrote: Live resize (without reboot even) is something being worked on for the future 10.x series. Looking forward to this, we can't offer cloud instances with FreeBSD until this happens. ___ 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
portmaster: hal-0.5.14_20 and xorg-server-1.7.7_6, 1 (re)installation fails
When running portmaster -d -w -r pcre because of the upgrade from pcre-8.31 to pcre-8.32 I encountered the following inconveniences: Upgrade to hal-0.5.14_20 failed with the message it needs intltool 0.40 which was installed at the time. First upgrading to intltool-0.41.1 solved this. When reinstalling xorg-server-1.7.7_6,1 with portmaster today: Making install in xkb mkdir: /usr/local/share/X11/xkb/compiled: No such file or directory mkdir: /usr/local/share/X11/xkb/compiled: No such file or directory So I checked /usr/local/share/X11/xkb/compiled and this is a symlink to /var/lib/xkb which did not exist at the time. I created /var/lib/xkb and the installation went fine then. There is one file installed in this location: README.compiled This worked, but is it the right solution? Does anyone know what changed maybe? This is on 9.1-RELEASE with a portstree just updated with portsnap. Previous versions of the ports were from about 20 days ago. Everything is installed the standard way. Just if someone runs into these issues these may be found in the list (or already have been solved in ports) Things like this do not happen too often. ___ 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: Upgrading FreeBSD 8.3 amd64
On Tue, 2012-12-18 at 18:42 +0100, Ralf Mardorf wrote: I want to test snd_hdspe. How can I upgrade from 8.2 to a version ^^^8.3 including the driver or something similar to get the driver? Btw. I didn't test, if the driver is part of 8.3 until now :D, but if IIUC I need = 9.0. I'll read http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html can I assume that because I didn't install or updated and configured anything until now, there won't be issues for a version upgrade, if I only configure PPPoE, followed by a release upgrade and after that I'll install software and set up FreeBSD completely? ___ 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: Upgrading FreeBSD 8.3 amd64
On Tue, 18 Dec 2012 18:42:41 +0100, Ralf Mardorf wrote: I want to test snd_hdspe. How can I upgrade from 8.2 to a version including the driver or something similar to get the driver? Btw. I didn't test, if the driver is part of 8.3 until now :D, but if IIUC I need = 9.0. It would probably be the easiest way to update your source tree (using svn as this is the default method today) and re-install from that. I'm not sure freebsd-update can cross the major version border without trouble (never tried). See 25.7 for details: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html But also note that freebsd-update supports a -r version option as explained in 25.2.3: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html But as I said, I've never personally tried that. This approach keeps all your partition settings and doesn't require any other work to be done on that level. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: Upgrading FreeBSD 8.3 amd64
On Tue, 2012-12-18 at 18:57 +0100, Polytropon wrote: On Tue, 18 Dec 2012 18:42:41 +0100, Ralf Mardorf wrote: I want to test snd_hdspe. How can I upgrade from 8.2 to a version including the driver or something similar to get the driver? Btw. I didn't test, if the driver is part of 8.3 until now :D, but if IIUC I need = 9.0. It would probably be the easiest way to update your source tree (using svn as this is the default method today) and re-install from that. I'm not sure freebsd-update can cross the major version border without trouble (never tried). See 25.7 for details: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html But also note that freebsd-update supports a -r version option as explained in 25.2.3: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html But as I said, I've never personally tried that. This approach keeps all your partition settings and doesn't require any other work to be done on that level. Thank you :) I'll read and test it later. Regards, Ralf ___ 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: Upgrading FreeBSD 8.3 amd64
On Tue, 18 Dec 2012 18:54:29 +0100, Ralf Mardorf wrote: On Tue, 2012-12-18 at 18:42 +0100, Ralf Mardorf wrote: I want to test snd_hdspe. How can I upgrade from 8.2 to a version ^^^8.3 including the driver or something similar to get the driver? Btw. I didn't test, if the driver is part of 8.3 until now :D, but if IIUC I need = 9.0. I'll read http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html can I assume that because I didn't install or updated and configured anything until now, there won't be issues for a version upgrade, if I only configure PPPoE, followed by a release upgrade and after that I'll install software and set up FreeBSD completely? Sounds like a valid approach. I've been doing this many times, i. e. first install base system from installation media without additional packages, setup networking (PPPoE in former times, DHCP today), then update the system to the desired version or branch (e. g. -STABLE via source), and then start installing the applications from ports (also updated). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: svn revision in uname
On Mon, Dec 17, 2012 at 2:13 PM, David Demelier demelier.da...@gmail.com wrote: I hope it will be removed soon, it pollutes the uname -a output. I don't hope so. It helps us keep track of the exact revision numbers of deployed servers here. Please don't remove it, or at least, provide an additional switch to uname to retrieve it. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: using AWK
On Mon, 17 Dec 2012 08:16:26 -0800
Devin Teske wrote:
On Dec 17, 2012, at 3:39 AM, Jack Mc Lauren wrote:
Hi guys
How can I read a file which contains a number and assign that
number to a variable via awk programming? By the way, I want to use
this awk program in a shell script.
Thanks in advance
Try this:
awk -v file=/etc/ttys 'BEGIN { getline line file; printf First line
from %s: %s\n, file, line }'
Semms a bit complicated when you could set the awk variable directly
e.g.
$ echo 42 /tmp/f
$ awk -v x=`cat /tmp/f` 'BEGIN{ print x+1 }'
43
___
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
updatedb?
$ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or 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: updatedb?
On Dec 18, 2012, at 1:01 PM, Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? You're missing the fact that updatedb essentially makes a list of every file on your disk (and that this list is able to be queried by anybody regardless of permissions or group membership). The best and most notable example of this constituting a security risk is if you've prevented access to a directory… root's home-directory (/root) for example. Illustratively, this would be if you did chmod go-wrx somedir so that only the owner could see inside it. When you run updatedb as root, it traverses all directories even those that you may have posted a big keep out sign on (aforementioned chmod). Then every non-privileged user on the system can list the contents of your secret hideout with the keep out sign posted on it. You might have well built that house out of glass (they can't read the contents of the books on your bookshelf, but they can see the covers and know what you've got stocked on the shelves). If this doesn't concern you, (and there's plenty of reasons to ignore this warning -- say, if you operate in a closed environment where trust isn't an issue and you value the ability to find any file on the system at any time) -- then proceed my friend, … proceed. Otherwise, it's best to think about running updatedb as a non-privileged user that (a) can't use built-in super-user privileges to bypass security settings when enumerating the UNIX filesystems you've configured in locate.conf(5) (optional -- by default it acts sensibly and ignores what you'd expect it to). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: updatedb?
On Tue, 18 Dec 2012 21:01:33 + (UTC), Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? Depends. In case you're using your system primarily as a single-user installation - no problem. If there are users who don't have trust in others (and this is _correct_), any call of locate something could reveal data stored on different user accounts, even if they cannot be accessed due to o-x for the individual home directories. Sometimes file names can already tell a lot. The locate.updatedb is usually run from the nobody user account when invoked automatically. This means that the directory restrictions can apply (e. g. user home directories cannot be searched when they have o-x attribute). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: updatedb?
On Tue, Dec 18, 2012 at 3:01 PM, Walter Hurry walterhu...@gmail.com wrote: Security through obscurity? Really? In this day and age? My password is obscured from you. I consider that more secure regardless of what any other opinion is. -- Adam Vande More ___ 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: updatedb?
On Tue, 18 Dec 2012 21:01:33 + (UTC) Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? If permissions have been set to prevent other users reading filenames then obviously leaking file names is security issue. ___ 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: updatedb?
On 12/18/12 22:32, RW wrote: On Tue, 18 Dec 2012 21:01:33 + (UTC) Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? If permissions have been set to prevent other users reading filenames then obviously leaking file names is security issue. Yes. But as stated before it defaults to run as user nobody. Line 26 /etc/periodic/weekly/310.locate echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3 No issue there. If someone runs it as root it can be, as everything being run as root, a security issue. ___ 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: updatedb?
On Tue, 18 Dec 2012 21:32:50 +, RW wrote: On Tue, 18 Dec 2012 21:01:33 + (UTC) Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? If permissions have been set to prevent other users reading filenames then obviously leaking file names is security issue. There are no leaking file names, as by command, the tool does what it is requested to: to not obey the restrictions that apply in its _normal_ use and list _all_ file names instead. See /etc/periodic/weekly/310.locate for example: The default call of locate.updatedb is this: echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3 The program (script) will additionally honor settings in the /etc/locate.rc file. So if the questioned use of sudo /usr/libexec/locate.updatedb to run it as root (with _all_ permissions!) leads to the intended behaviour, i. e. list _all_ files on the system, that isn't actually a leak, I'd say. (Terminology: A leak would appear if you'd run locate.updatedb with the nobody user, and still file names from inside a o-rwx directory would appear!) I really like the analogy provided by Devin Teske in his reply: When you run updatedb as root, it traverses all directories even those that you may have posted a big keep out sign on (aforementioned chmod). Then every non-privileged user on the system can list the contents of your secret hideout with the keep out sign posted on it. You might have well built that house out of glass (they can't read the contents of the books on your bookshelf, but they can see the covers and know what you've got stocked on the shelves). Again: If that's intended, locate.updatedb will act as instructed. Oh behold the unlimited power of root. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: updatedb?
On Tue, Dec 18, 2012 at 10:01 PM, Walter Hurry walterhu...@gmail.com wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? Suppose someone managed to start a shell under your account and is seeking to escalate privileges, i.e. to become root. If he can look at a full unrestricted locatedb, he may pay particular attention to config files, log files etc... that may otherwise be hidden from sight. Just by looking at this, he may infer that a particular software package at a particular revision is actually running on that host and is configured in a particular way. E.g., he may see that logfiles accumulate in /var/log and are cleaned only once a week. It would be then easy to induce that program to create more log files, thus denying service to other programs that need /var as well. This, in turn, could result in real exploits of those other programs... Sure, most of this is already world-visible and in the regular locatedb because we're so liberal with the rights of /var/db/pkg, /var/log, /etc, ... but some admins prefer to hide particularly sensitive programs, their configs, logs etc., in a non-world-readable directory hierarchy. Running locate.updatedb(8) with root privileges would defeat that strategy. That's why it is discouraged. Of course, this is even more necessary when you have regular users on that machine that don't necessarily trust each others. They wouldn't like their home dirs to be world-readable by default by everyone else. Maybe they won't object (and set /home/$USER to -rwxr-xr-x instead of -rwxr-x--- or -rwx--) but that's their call, not the sysadmin's. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: updatedb?
On 12/18/12 23:04, C. P. Ghost wrote: On Tue, Dec 18, 2012 at 10:01 PM, Walter Hurry walterhu...@gmail.com wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? Suppose someone managed to start a shell under your account and is seeking to escalate privileges, i.e. to become root. If he can look at a full unrestricted locatedb, he may pay particular attention to config files, log files etc... that may otherwise be hidden from sight. locate.updatebd is _not_ run as root by default. See Polytropon's and other replies. If root runs it, it is root's responsibility that others can obtain all filenames on the system. Just by looking at this, he may infer that a particular software package at a particular revision is actually running on that host and is configured in a particular way. E.g., he may see that logfiles accumulate in /var/log and are cleaned only once a week. It would be then easy to induce that program to create more log files, thus denying service to other programs that need /var as well. This, in turn, could result in real exploits of those other programs... Sure, most of this is already world-visible and in the regular locatedb because we're so liberal with the rights of /var/db/pkg, /var/log, /etc, ... but some admins prefer to hide particularly sensitive programs, their configs, logs etc., in a non-world-readable directory hierarchy. Running locate.updatedb(8) with root privileges would defeat that strategy. That's why it is discouraged. Of course, this is even more necessary when you have regular users on that machine that don't necessarily trust each others. They wouldn't like their home dirs to be world-readable by default by everyone else. Maybe they won't object (and set /home/$USER to -rwxr-xr-x instead of -rwxr-x--- or -rwx--) but that's their call, not the sysadmin's. -cpghost. ___ 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: svn revision in uname
David Demelier demelier.da...@gmail.com writes: 2012/12/15 Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org Anders N. wic...@baot.se writes: Hi. I've noticed in my uname -a on 9.1-RELEASE there is r243826. This is on a system that upgraded from 9.1-RC3 using freebsd-update (binary). On another system, upgraded from 9.0-RELEASE via freebsd-update (source), there is nothing at all and uname -a looks normal. Two other people I asked have r243825 (installed from ISO) and r243872 (upgraded from svn). They're all 9.1-RELEASE, shouldn't they be the same, final version? As I understand it, the revision ID refers to the whole repository, not just a branch. So if you do your own svn checkout tomorrow, you'll get yet another revision number, even though the files will (probably) be completely identical to what you checked out yesterday -- ongoing commits to HEAD will keep kicking the revision number up. There is work going on to make system builds completely, bit-for-bit, repeatable, but that will presumably mean getting rid of this revision number information, not making it consistent. I hope it will be removed soon, it pollutes the uname -a output. It's easy enough to add a stage in the kernel build to remove it if you don't like it, but in most source-update environments it's a very valuable piece of information. Even if a reproduceable-build infrastructure is put in place, it would have to be optional because this information is necessary in heterogeneous environments. I don't know that anyone's working on it the moment -- I *thought* I'd read something about it recently, but I can't find any reference to such an effort this year. ___ 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: updatedb?
On Tue, 18 Dec 2012 22:53:29 +0100 Polytropon wrote: On Tue, 18 Dec 2012 21:32:50 +, RW wrote: On Tue, 18 Dec 2012 21:01:33 + (UTC) Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? If permissions have been set to prevent other users reading filenames then obviously leaking file names is security issue. There are no leaking file names, There is from the perspective of an ordinary user that's configured directories under ~ to be confidential. as by command, the tool does what it is requested to: to not obey the restrictions that apply in its _normal_ use and list _all_ file names instead. Obviously. But the warning is intended for people that haven't thought through the consequences of what they are doing. On Tue, 18 Dec 2012 22:49:43 +0100 Bas Smeelen wrote: Yes. But as stated before it defaults to run as user nobody. Line 26 /etc/periodic/weekly/310.locate echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3 This is true but not very relevant. It runs as nobody from the periodic script, but the warning comes from locate.updatedb itself, which may be run independently of 310.locate. If someone runs it as root it can be, as everything being run as root, a security issue. Not really, mostly when things are run as root there is an additional risk. Very few things do the wrong thing simply as a consequence of running as root so it warrants a warning. ___ 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: updatedb?
On 12/18/12 23:44, RW wrote: On Tue, 18 Dec 2012 22:53:29 +0100 Polytropon wrote: On Tue, 18 Dec 2012 21:32:50 +, RW wrote: On Tue, 18 Dec 2012 21:01:33 + (UTC) Walter Hurry wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? If permissions have been set to prevent other users reading filenames then obviously leaking file names is security issue. There are no leaking file names, There is from the perspective of an ordinary user that's configured directories under ~ to be confidential. as by command, the tool does what it is requested to: to not obey the restrictions that apply in its _normal_ use and list _all_ file names instead. Obviously. But the warning is intended for people that haven't thought through the consequences of what they are doing. Agree. It is good to be there. Should be clear to Walter I guess. It is not security through obscurity, it is security by permissions and controls, and root can circumvent these and expose potential security risks by information to others or the world, thus the warning when running it as root. Thanks. On Tue, 18 Dec 2012 22:49:43 +0100 Bas Smeelen wrote: Yes. But as stated before it defaults to run as user nobody. Line 26 /etc/periodic/weekly/310.locate echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3 This is true but not very relevant. It runs as nobody from the periodic script, but the warning comes from locate.updatedb itself, which may be run independently of 310.locate. If someone runs it as root it can be, as everything being run as root, a security issue. Not really, mostly when things are run as root there is an additional risk. Very few things do the wrong thing simply as a consequence of running as root so it warrants a warning. Fully agree. Root can be a liability though. ___ 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: updatedb?
On 12/18/12 23:04, C. P. Ghost wrote: On Tue, Dec 18, 2012 at 10:01 PM, Walter Hurry walterhu...@gmail.com wrote: $ sudo /usr/libexec/locate.updatedb WARNING Executing updatedb as root. This WILL reveal all filenames on your machine to all login users, which is a security risk. $ Why is it a security risk? Security through obscurity? Really? In this day and age? Or am I missing something? Suppose someone managed to start a shell under your account and is seeking to escalate privileges, i.e. to become root. If he can look at a full unrestricted locatedb, he may pay particular attention to config files, log files etc... that may otherwise be hidden from sight. Just by looking at this, he may infer that a particular software package at a particular revision is actually running on that host and is configured in a particular way. E.g., he may see that logfiles accumulate in /var/log and are cleaned only once a week. It would be then easy to induce that program to create more log files, thus denying service to other programs that need /var as well. This, in turn, could result in real exploits of those other programs... Sure, most of this is already world-visible and in the regular locatedb because we're so liberal with the rights of /var/db/pkg, /var/log, /etc, ... but some admins prefer to hide particularly sensitive programs, their configs, logs etc., in a non-world-readable directory hierarchy. Running locate.updatedb(8) with root privileges would defeat that strategy. That's why it is discouraged. Of course, this is even more necessary when you have regular users on that machine that don't necessarily trust each others. They wouldn't like their home dirs to be world-readable by default by everyone else. Maybe they won't object (and set /home/$USER to -rwxr-xr-x instead of -rwxr-x--- or -rwx--) but that's their call, not the sysadmin's. -cpghost. Sorry, cpghost, I missed the point. Clear explanation. Should such programs be modified so there is never a change to being run as root? I guess there are environments where measures like these are taken, no warning, just refuse to run as root? ___ 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
which C function is best to check for directory EXISTANCE?
which C function is best to check for the existence of a *directory*? say that I am want to make postitve that /tmp/foo/ exists. ALso: which will make sure that the directory AND ffile tmp/foo/filename12345 exists and that I have read access to it? in other words, can playing around with access() and stat() be best? is there any new dirstat(PATh) that would work? just want to see which way is best? dank mucho, y'all! gary -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix Twenty-six years of service to the Unix community. ___ 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: which C function is best to check for directory EXISTANCE?
On Tue, 18 Dec 2012 16:26:10 -0800, Gary Kline wrote: which C function is best to check for the existence of a *directory*? say that I am want to make postitve that /tmp/foo/ exists. That can be done with the opendir() function; its manpage lists other interesting follow-up functions to work with. ALso: which will make sure that the directory AND ffile tmp/foo/filename12345 exists and that I have read access to it? You can use readdir() and parse its output. If you already know the file name, use a fopen() call for the mode you're trying to open it with (e. g. r or w) to see if the permissions are set accordingly. Also ferror() can be used to test for specific errors that may occur during file operations. in other words, can playing around with access() and stat() be best? That also sounds possible. In case you're going to continue to operate with the file in question, certain functions sound better. But for the pure testing, access() and stat() provide sufficient functionality. is there any new dirstat(PATh) that would work? $ man dirstat No manual entry for dirstat :-) just want to see which way is best? Depends. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: Somewhat OT: Is Full Command Logging Possible?
Tim Daneliuk wrote at 17:48 -0600 on Dec 5, 2012: On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. snip sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? See log_input and log_output in sudoers(5) ___ 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: Somewhat OT: Is Full Command Logging Possible?
On 12/18/2012 06:53 PM, John Hein wrote: Tim Daneliuk wrote at 17:48 -0600 on Dec 5, 2012: On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. snip sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? See log_input and log_output in sudoers(5) Thanks so much John, that's the secret sauce I was looking for... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Somewhat OT: Is Full Command Logging Possible?
On 12/18/2012 07:09 PM, Tim Daneliuk wrote: On 12/18/2012 06:53 PM, John Hein wrote: Tim Daneliuk wrote at 17:48 -0600 on Dec 5, 2012: On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. snip sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? See log_input and log_output in sudoers(5) Thanks so much John, that's the secret sauce I was looking for... One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Somewhat OT: Is Full Command Logging Possible?
On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: On 12/18/2012 07:09 PM, Tim Daneliuk wrote: On 12/18/2012 06:53 PM, John Hein wrote: Tim Daneliuk wrote at 17:48 -0600 on Dec 5, 2012: On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. snip sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? See log_input and log_output in sudoers(5) Thanks so much John, that's the secret sauce I was looking for... One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). I've suggested the lrexec module for catching everything, or you can look into the auditdistd (distributed auditing collection/collation to a remote/central server) approach, the praudit approach, or any of the other pieces of software mentions. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Somewhat OT: Is Full Command Logging Possible?
On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. I've suggested the lrexec module for catching everything, or you can look into the auditdistd (distributed auditing collection/collation to a remote/central server) approach, the praudit approach, or any of the other pieces of software mentions. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Somewhat OT: Is Full Command Logging Possible?
On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote: On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. What about if you do sudo vim and then type :sh ? -- Devin I've suggested the lrexec module for catching everything, or you can look into the auditdistd (distributed auditing collection/collation to a remote/central server) approach, the praudit approach, or any of the other pieces of software mentions. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Somewhat OT: Is Full Command Logging Possible?
On 12/18/2012 08:03 PM, Devin Teske wrote: On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote: On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. What about if you do sudo vim and then type :sh ? Yep, I just tried that too. It catches that. It also catches the in/output of subshells - like, say, kicking off sh interactively. Similarly, if you're running text-based emacs, it catches the output of spawning to a shell from there and doing things. The only restriction I have run into so far, it that - for obvious reasons - sudo cannot see into what you're doing if you kick off an X application like xterm or graphical emacs, for instance. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Somewhat OT: Is Full Command Logging Possible?
On 12/18/2012 08:20 PM, Tim Daneliuk wrote: On 12/18/2012 08:03 PM, Devin Teske wrote: On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote: On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. What about if you do sudo vim and then type :sh ? Yep, I just tried that too. It catches that. It also catches the in/output of subshells - like, say, kicking off sh interactively. Similarly, if you're running text-based emacs, it catches the output of spawning to a shell from there and doing things. The only restriction I have run into so far, it that - for obvious reasons - sudo cannot see into what you're doing if you kick off an X application like xterm or graphical emacs, for instance. I should clarify that I tested this not on FreeBSD but on a Mint Linux desktop I had handy. I would expect the same behavior everywhere, though, since sudo itself is reasonably portable... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: which C function is best to check for directory EXISTANCE?
On Tue, 18 Dec 2012 16:26:10 -0800, Gary Kline kl...@thought.org said: G which C function is best to check for the existence of a *directory*? G say that I am want to make postitve that /tmp/foo/ exists. ALso: G which will make sure that the directory AND file G tmp/foo/filename12345 exists and that I have read access to it? I'd just call open() with O_RDONLY and if it fails, check errno for EACCESS (you don't have permission) or ENOENT (doesn't exist). -- Karl Vogel I don't speak for the USAF or my company USELESS PHRASES WHEN SPEAKING TO A COP #9: You're not gonna check the trunk, are you? ___ 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: Somewhat OT: Is Full Command Logging Possible?
On Dec 18, 2012, at 6:20 PM, Tim Daneliuk wrote: On 12/18/2012 08:03 PM, Devin Teske wrote: On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote: On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. What about if you do sudo vim and then type :sh ? Yep, I just tried that too. It catches that. It also catches the in/output of subshells - like, say, kicking off sh interactively. Similarly, if you're running text-based emacs, it catches the output of spawning to a shell from there and doing things. The only restriction I have run into so far, it that - for obvious reasons - sudo cannot see into what you're doing if you kick off an X application like xterm or graphical emacs, for instance. What about screen or tmux? (wondering if the transition into multiplexed shell is anywhere as opaque as X11). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Somewhat OT: Is Full Command Logging Possible?
On 12/18/2012 10:10 PM, Devin Teske wrote: On Dec 18, 2012, at 6:20 PM, Tim Daneliuk wrote: On 12/18/2012 08:03 PM, Devin Teske wrote: On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote: On 12/18/2012 07:33 PM, Devin Teske wrote: On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote: One further question, if I may. If I do this: sudo su - Will log_input record everything I do once I've been promoted to root? I ask because my initial experiments seem to show that all that's getting recorded is the content of the sudo command itself, not the subsequent actions… Correct, sudo is blind to the actions performed once the command requested is executed (in this case, su and subsequently a shell followed by more actions). Actually, I just tried this with both log_input and log_output options enabled. It seems that it *can* see into the promoted shell with a few caveats: - Command output is logged immediately, but command inputs appear to only be written to the log when you exit the promoted shell. This may be not quite right - there may have not been enough input to cause a write flush to the log. - The logging seems to be able to see into a spawned subshell, but I don't think it can see input/output if you, say, kick off an xterm. What about if you do sudo vim and then type :sh ? Yep, I just tried that too. It catches that. It also catches the in/output of subshells - like, say, kicking off sh interactively. Similarly, if you're running text-based emacs, it catches the output of spawning to a shell from there and doing things. The only restriction I have run into so far, it that - for obvious reasons - sudo cannot see into what you're doing if you kick off an X application like xterm or graphical emacs, for instance. What about screen or tmux? (wondering if the transition into multiplexed shell is anywhere as opaque as X11). It definitely works if you are in a screen session and sudo su - from there. I have not tried promoting myself to root and THEN starting the screen session (I don't use tmux). -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
CPU upgrade vs CPUTYPE
Hello! We have a small server running FreeBSD 8.3 amd64 with Intel Pentium D 945 CPU. As the motherboard/CPU combo is getting rather old, we are considering an upgrade to new motherboard with Xeon E3-1230 CPU. We currently have these CPU settings in /etc/make.conf: CPUTYPE?=nocona in kernel configuration: cpu HAMMER Almost all the software is built from ports, few bits compiled directly from source. Base system is maintained by buildworld. Can we expect the software compiled with above CPU settings to run without problems on the Xeon E3? We had a chance recently to try a temporary motherboard/CPU swap in this server, replacing the CPU with Core i3-2xxx and there were some 'signal 11' errors, but I'm not sure whether this was due to incompatible CPUTYPE or something else. Thanks in advance, -- Toomas Aas ___ 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: CPU upgrade vs CPUTYPE
Cross-posting reply to amd64@ for relevance and to get answers from those smart gents. On 12/18/12 23:17, Toomas Aas wrote: Hello! We have a small server running FreeBSD 8.3 amd64 with Intel Pentium D 945 CPU. As the motherboard/CPU combo is getting rather old, we are considering an upgrade to new motherboard with Xeon E3-1230 CPU. We currently have these CPU settings in /etc/make.conf: CPUTYPE?=nocona in kernel configuration: cpu HAMMER this is the only possible setting in the kernel conf for amd64 as I was told. This was why (and might answer the make.conf question as well: from b.f.: Leave it alone. The choices for the cpu directive in the kernel config file, as described in config(5) and listed in src/sys/conf/options.arch (the only choice for amd64 is HAMMER), have nothing to do with the choices available for the CPUTYPE variable (which you may want to change to suit your hardware -- these are the architecture-dependent options available for the -march and -mtune directives of your compiler that are also recognized by bsd.cpu.mk), or with the cpu descriptions printed during boot. As for the rest of your questions, I leave them in the hands of those more knowledgeable than I. HTH Almost all the software is built from ports, few bits compiled directly from source. Base system is maintained by buildworld. Can we expect the software compiled with above CPU settings to run without problems on the Xeon E3? We had a chance recently to try a temporary motherboard/CPU swap in this server, replacing the CPU with Core i3-2xxx and there were some 'signal 11' errors, but I'm not sure whether this was due to incompatible CPUTYPE or something else. Thanks in advance, -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.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
