Date: Fri, 25 Jan 2013 15:04:14 +0100 From: Polytropon <freebsd@edvax.de> To: "Ralf Mardorf" <ralf.mardorf@rocketmail.com> Cc: FreeBSD quest <freebsd-questions@freebsd.org> Subject: Re: Sharing a mail folder between Linux and FreeBSD Message-ID: <20130125150414.f262d162.freebsd@edvax.de> In-Reply-To: <op.wrgzatq7uwjkcr@freebsd> References: <op.wrguj103uwjkcr@freebsd> <20130125133346.f1484ed8.freebsd@edvax.de> <op.wrgzatq7uwjkcr@freebsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jan 2013 14:48:19 +0100, Ralf Mardorf wrote: > On Fri, 25 Jan 2013 13:33:46 +0100, Polytropon <freebsd@edvax.de> wrote: > >> $ ls -l `which su` > >> -r-sr-xr-x 1 rocketmouse wheel 16880 Dec 23 18:38 /usr/bin/su > > > > Erm... that looks horribly wrong. > > > > The permissions indicate that setuid is set, but the file > > owner is wrong. For comparison: > > > > -r-sr-xr-x 1 root wheel 14604 2011-08-21 20:24:28 /usr/bin/su* > > > > This program has to belong to root. It seems that your > > attempt to reflect UID changes in the file permissions > > exceeded the scope of this task: Programs of the OS > > seem to be affected, which is definitely not good. > > IMO setuid alone already is a security risk. The su program is part of the operating system, so it can safely be considered safe. :-) > >> $ ls -l /home/ | grep rocketmouse > >> drwxr-xr-x 28 rocketmouse rocketmouse 1536 Jan 25 12:17 > >> rocketmouse > > > > You can use ls -ld to omit the grep step. :-) > > $ ls -ld /home/rocketmouse > drwxr-xr-x 28 rocketmouse rocketmouse 1536 Jan 25 13:19 > /home/rocketmouse > > :) > > I was sure that using grep is stupid and should have done a 'man ls', > since 'help' wasn't helpful. That's why "man ls" exists. :-) > This issue and 'cat | grep' instead of grep > only are common mistakes by many Linux users. This reminds me to "useless use of 'cat'" which is often used because it constructs a convenient and easy to read "chain" of commands, but can often be avoided, especially when files can be redirected from. > > Do you have other files in /usr or even /usr/local that do > > belong to rocketmouse (uid == 1000 or 1001) now? That should > > not have happened... > > /usr/bin is ok > /usr/include is ok > /usr/include/* seem to be ok, I just checked some > folders > /usr/lib and /usr/lib/* are ok > /usr/libdata and /usr/libdata/* are ok > /usr/libexec and /usr/libexec/*/* are ok > /usr/ports is ok > /usr/ports/* seem to be ok, I just checked some > folders > /usr/sbin is ok > /usr/share is ok > /usr/share/* seem to be ok, I just checked some > folders > /usr/src is ok > /usr/src/*/* seem to be ok, I just checked some > folders > > /usr/local is ok > /usr/local/bin and /usr/local/bin/* are ok > /usr/local/bootstrap* and [...]/* are ok > /usr/local/etc is ok > /usr/local/etc/* seem to be ok, at least PolicyKit and > ConsoleKit are > /usr/local/include is ok > [snip] > > All /usr/local/* are ok and all /usr/local/*/* seem to be ok. > Other directories in /usr and /usr/local are empty. You can do something like this: % ls -lR / | grep -v "/home" | grep "rocketmouse" This will probably show some "false-positives" in /tmp and maybe in /var, but should show nothing in /usr directly (or in other top level system directories). > OT: /usr/lib32 and /usr/lib32/* belong to the empty folders in /usr. Allow me a polite note regarding terminology: There are no folders. Those are called directories. This is the valid technical term. A "folder" is the name of a typical GUI representation element _for_ a directory. Relations: "is a" vs. "represents a" or "looks like a". I know it's common to call directories "folders", but this is as wrong as calling a device driver "Bob". ;-) > So > FreeBSD is multi arch capable? > (since there's /usr/ports/astro/google-earth for amd64, I suspect it is) The system shares some stuff across architectures, and it's possible to run 32 bit applications on a 64 bit system, so specific "fixed bit width libraries" are provided. This is reflected in naming conventions. Even though the installer might create those directories in advance, it's possible that they only receive content under specific circumstances. Ports do usually work on both systems. Those that do _not_ have a checking mechanism in their Makefile that indicates on which platform they don't build, or if they are designed for one specific platform only. > > Some programs check by whom they are called or who they > > belong to; if that's != root when it is _supposed_ to > > be root, that can cause problems, especially when it's > > not a simple x (execute), but s (setuid) program like > > an X display manager. > > So I guess I only need to correct the owner for /usr/bin/su. If that's the only occurance, it should be sufficient. > $ ls -l /usr/bin/su > -r-sr-xr-x 1 root wheel 16880 Dec 23 18:38 /usr/bin/su > > I wonder if setting suid is needed, while the kit family is installed. For > sure it's possible to add a rool to some kit config. The su program is part of the OS, while things like PolicyKit are additional software. It sounds doubleplusungood to modify a standard (!) system setting at file permission level for such a purpose. > Restart > > PPPoE was enabled automagically :). You probably have the required magic in /etc/rc.conf. :-) > $ su > Password: > You have mail. > root@freebsd:/usr/home/rocketmouse # :) > > Ctrl + Alt + F* will switch to ttyv* and su does work too. :) Because su will work everywhere it's supposed to work. :-) > So the switch to uid 1000 seem to be complete now, without any gaps. Just to make sure, check with the ls | grep command listed above. Nothing "surprising" should show up in the result. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130125150414.f262d162.freebsd>