httpd newbie / access denied, no permission to ~userid

[Tim]

Paul Howarth wrote:
 
>>> You could take this argument further: any file with "world readable" 
>>> permissions should automatically be readable via the local web server 
>>> (an entry in httpd.conf should be made to allow it). After all, it's 
>>> world readable. Does that make sense?

Tim:
 
>> Yes, and that was precisely the point I was arguing.  I'd made a file's
>> permissions so that it was available to everybody, so it should be...

Paul Howarth wrote:

> So running "chmod a+r /path/to/filename" should automatically cause an 
> edit of httpd.conf so that /path/to/filename is available by http for 
> all to read? I thought I chose a particularly outrageous example but 
> apparently not.

I misunderstood your intension.  I was thinking along the lines that if
I set something to be world readable, and there was an option within the
Apache config that says it's okay to server *any* world readable file,
that it would do so.

> Making a file's permissions world-readable *does* make it available to 
> everybody, i.e. all users equally. However, SELinux (at least for the 
> targeted policy) imposes restrictions on what *processes* (not *users*) 
> can do. This is how it should be IMHO.

At what level do you stop, though?

If you're allowing access at a program level, make this file useable
with an FTP server, plus HTTP server, plus SMB server, then the ls
program, the less program the more program, ad infinitum?

Or allow system utilities as a group (less, more, ls, etc.), system
services as a group, and so on...

This sort of control seems excessive at best, and unworkable at worst.

> How about another example. Suppose you're running samba. You can specify 
> in samba that individual shares are available only to certain users. So 
> if /path/to/filename is accessible via such a share, then even though it 
> may be world-readable on the samba server itself, only the specified 
> list of users can access it via samba. This is a layering of access 
> rights, with the samba restrictions sitting on top of the Unix 
> permissions.

This is also something that I find to be a complete pain.  Sharing files
through Samba can be a right mess.  With permissions getting changed, or
needing to be changed, for it work.  I see the need for using Samba when
interfacing Linux and Windows, but it's something I work hard to avoid
using between Linux boxes.

> Only if both say "OK" is access granted. SELinux works in a 
> similar fashion, layering an additional set of restrictions on top of 
> the Unix permissions. The two are completely separate and should not 
> affect each other. Removing one set of restrictions should not result in 
> the removal of all other sets.

Which is okay, in one sense.  But it'd sure help if there was one
utility that allowed you to set both permission types at the same time.
Yes, only allow users to set sensible controls on their own files.  They
don't need to be able to modify how servers will use those files (server
configuration).  There's some awful muddying of the waters, now, between
file permissions and service permissions.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.