This is correct behaviour. If you need to modify some entry you added before, use -m,--modify:

# semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/app\.cgi'
# semanage fcontext -m -t httpd_sys_script_exec_t '/var/www/app\.cgi'

(In reply to Petr Lautrbach from comment #1)
> This is correct behaviour. If you need to modify some entry you added
> before, use -m,--modify:
> 
> # semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/app\.cgi'
> # semanage fcontext -m -t httpd_sys_script_exec_t '/var/www/app\.cgi'

That is not my use-case. I do not want to modify anything.

sh# semanage fcontext -d -t httpd_sys_script_exec_t '/var/www/app\.cgi'
sh# semanage fcontext -m -t httpd_sys_script_exec_t '/var/www/app\.cgi'
ValueError: File context for /var/www/app\.cgi is not defined


I want to have just fcontext there with right parametrs. (and fail only if there is different conflicting context. I would expect more idempotent behaviour.
Or do you have semanage module for configure management tool (ansible, puppet ...)

(In reply to Lukas Slebodnik from comment #2)
> (In reply to Petr Lautrbach from comment #1)
> > This is correct behaviour. If you need to modify some entry you added
> > before, use -m,--modify:
> > 
> > # semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/app\.cgi'
> > # semanage fcontext -m -t httpd_sys_script_exec_t '/var/www/app\.cgi'
> 
> That is not my use-case. I do not want to modify anything.
> 

But if modify will be idempotent (it will add entry in case of non existing one
then I will be glad to use it.

> sh# semanage fcontext -d -t httpd_sys_script_exec_t '/var/www/app\.cgi'
> sh# semanage fcontext -m -t httpd_sys_script_exec_t '/var/www/app\.cgi'
> ValueError: File context for /var/www/app\.cgi is not defined
> 
> 
> I want to have just fcontext there with right parametrs. (and fail only if
> there is different conflicting context. I would expect more idempotent
> behaviour.
> Or do you have semanage module for configure management tool (ansible,
> puppet ...)

'semanage fcontext [-a|-m]' works with local policy modifications. You can list these modifications using:

# semanage fcontext -l -C        

or you can extract them:

# semanage fcontext -E

The output of the command above can be used as an  input for 'semanage import' later.


If you need add a new file context mapping which is not defined in local modifications yet, you need to use -a, --add:

# semanage fcontext -a -t httpd_sys_script_exec_t '/opt/.*\.cgi'

When you try add this again, it fails since it's already defined and you need to use -m, --modify:

# semanage fcontext -a -t httpd_sys_script_exec_t '/opt/.*\.cgi'
ValueError: File context for /opt/.*\.cgi already defined

# semanage fcontext -m -t httpd_sys_script_exec_t '/opt/.*\.cgi'

You can also use -D option to delete all local modifications before you add a new one:

# semanage fcontext -D

# semanage fcontext -a -t httpd_sys_script_exec_t '/opt/.*\.cgi'


If you need to manage local SELinux policy setting you can try linux-system-roles.selinux Ansible role - https://github.com/linux-system-roles/selinux

I think an idempotent option (or default behaviour, since duplicates
don't make sense) would be an improvement. I wind up using a `||` in
the shell with the same code written twice, one with "-a" and one with
"-m". Obviously it's brittle if only one copy is changed, or I have to
add abstraction to avoid that that is not always worth the trouble,
but the status quo is not graceful.

I agree this is a bug.  Adding a rule that is already there - exactly as specified - should not be an error.  Perhaps it merits a warning (not error exit status).  Adding a rule that is a change can continue to emit an error.

Also there should be a way to query a particular rule (not only grep the full list of rules).  That would allow the script to check for a rule's existence before adding.  But that's more burden on the script.

Querying the full list of fcontext rules and trying to match the pattern you are trying to add is cumbersome, inefficient, and fragile (getting the matching logic just right is something the tool should be able to do - not script writers reinventing parsing logic).

I would re-open this or maybe I will open a new bug, but I'd like to hear some discussion despite the age of this bug (rather than rehash everything that has already been discussed in a new location).