Question about file permissions
in [Suse]
|
From: Will Honea on 9 Apr 2010 22:19 marrgol wrote: > I believe you can; make sure your filesystem is mounted with "acl" > option and that you have "acl" packet installed, then try this > (for your chosen location you need to do it as root): > > ~ # mkdir /home/appdir > ~ # ls -ld /home/appdir > drwxr-xr-x 2 root root 4096 Apr 10 01:11 /home/appdir > ~ # setfacl -m g::rwx -m o::rwx -m default:g::rwx -m default:o::rwx \ > /home/appdir > ~ # > > Then as any user you can do: > > ~ $ touch /home/appdir/file1 > ~ $ mkdir /home/appdir/dir1 > ~ $ touch /home/appdir/dir1/file2 > ~ $ ls -lR /home/appdir > /home/appdir: > total 4 > drwxrwxrwx+ 2 marrgol users 4096 2010-04-10 01:13 dir1 > -rw-rw-rw- 1 marrgol users 0 2010-04-10 01:12 file1 > > /home/appdir/dir1: > total 0 > -rw-rw-rw- 1 margo users 0 2010-04-10 01:13 file2 > ~ $ > > As you can see both 'group' and 'others' have full access > to the files and directory I created, even though I have: > > ~ $ umask > 0077 > ~ $ Now we're getting to what I was foundering over! That appears to work just the way I wanted it to. setfacl was the piece I was missing. Thanks. -- Will Honea
From: Günther Schwarz on 10 Apr 2010 01:01 Will Honea wrote: > marrgol wrote: >> ~ # mkdir /home/appdir >> ~ # ls -ld /home/appdir >> drwxr-xr-x 2 root root 4096 Apr 10 01:11 /home/appdir ~ # setfacl -m >> g::rwx -m o::rwx -m default:g::rwx -m default:o::rwx \ /home/appdir >> ~ # > Now we're getting to what I was foundering over! That appears to work > just the way I wanted it to. setfacl was the piece I was missing. Instead of giving write access to everybody it might be preferable to create a new group for the users of the application and granting write access for this group only with acl. Something like g:database:rw Günther
From: Will Honea on 10 Apr 2010 12:35 Günther Schwarz wrote: > Will Honea wrote: > >> marrgol wrote: > >>> ~ # mkdir /home/appdir >>> ~ # ls -ld /home/appdir >>> drwxr-xr-x 2 root root 4096 Apr 10 01:11 /home/appdir ~ # setfacl -m >>> g::rwx -m o::rwx -m default:g::rwx -m default:o::rwx \ /home/appdir >>> ~ # > >> Now we're getting to what I was foundering over! That appears to work >> just the way I wanted it to. setfacl was the piece I was missing. > > Instead of giving write access to everybody it might be preferable to > create a new group for the users of the application and granting write > access for this group only with acl. Something like g:database:rw Good point. I have already done that - seemed obvious to me but it should be stressed more in the original discussion. This was a case where I had to share the database to many users while excluding several other users so the group spec was a no-brainer. I'm still new enough to Linux that I'm just not that familiar with the plethora of available tools yet. The matter became even more immediate when I reviewed the system log this morning - page after page of someone running a dictionary attack on the ssh port -- Will Honea
From: Vahis on 11 Apr 2010 04:35 On 2010-04-10, houghi <houghi(a)houghi.org.invalid> wrote: > Will Honea wrote: >> The matter became even more immediate when I reviewed the system log this >> morning - page after page of someone running a dictionary attack on the ssh >> port > > Install BlockHosts: > http://www.aczoom.com/cms/blockhosts/ I strongly second that. When configured correctly it stops all invalid login attempts in ssh and ftp and whatever. Great tool. > > Another advantage is that it is 'live'. Also very true. Adjustable number of invalid attempts leads to closing the IP in question. And, of course, for an adjustable period of time. > > Other people have other ways which I do not like for different reasons. > I mention them just to be complete: > 1) Change the port from 22 to something different I did that some months ago. No more invalids. As you brought up blockhosts I must admit that moving the ssh port is so effective that I had forgotten to install blockhosts in my current setup which I installed several weeks ago. > Using BlockHost is a great way to keep your logfiles clean. I personally > do NOT see it as security (unless through obscurity). A different port I > also do not see as security. Whitelisting can be, depending on how much > you trust the things you whitelist. If the configurations are made correctly and the passwords are strong there's not much point in blocking ssh. It's just the logs they affect and they are rotated, so... Vahis -- http://waxborg.servepics.com openSUSE 11.2 (x86_64) 2.6.31.12-0.2-default 11:26am up 16 days 14:44, 14 users, load average: 0.56, 0.45, 0.34
From: Shmuel Metz on 11 Apr 2010 08:41
In <WPewn.94515$y13.46465(a)newsfe12.iad>, on 04/11/2010 at 01:25 AM, Will Honea <whonea(a)yahoo.com> said: >(do they still classify them as A, B, C?) Theoretically, but CIDR has pretty much taken over. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap(a)library.lspace.org |