Tim: >> For instance, I'd tried using some CGI (and other languages) scripts to >> do various things, such as show a man page in the browser. To do so >> with SELinux would require changing lots of permissions in various >> places. It's tedious to do, and not intuitive (there's some damn awful >> labelling involved with SELinux). Rahul Sundaram wrote: > should be easy enough to enable httpd_enable_cgi if it isnt already. The > following Apache related booleans are available > > allow_httpd_anon_write --> inactive > allow_httpd_sys_script_anon_write --> inactive > httpd_builtin_scripting --> active > httpd_can_network_connect --> inactive > httpd_disable_trans --> inactive > httpd_enable_cgi --> active > httpd_enable_homedirs --> active > httpd_ssi_exec --> active > httpd_suexec_disable_trans --> inactive > httpd_tty_comm --> inactive > httpd_unified --> active That wasn't the problem. The real problem (i.e. horrible mess to deal with), is when your script wants to read from other files on the system (e.g. man files, fortune cookie files, etc.). You have to change their permissions to be HTTP servable, even if they were already world-readable. > You can use system-config-securitylevel or setsebool There isn't a correspondingly simple way to change the restrictions on files and directories, SELinux labels still aren't even just *displayed* in file property dialogues. You've got to type in really arcane labelnames to adjust SELinux restrictions on files. Really, how difficult would it have been for WORLD READABLE file permissions to be treated as such by SELinux? > http://www.nsa.gov/selinux/papers/inevit-abs.cfm (Inevitable-angst from BS?) :-\ I've had a look through their site before. It's not something that leaves a good impression on me. -- Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
