1. I thought such scheme will require 12 rules, but actually it required 22 
rules, also becasue some acls, like link, rename, etc. have two arguments (like 
new_path, old_path) which should be checked separately.

# grep BACK policy/current
1 acl write path=@BACKUPS
1 acl append path=@BACKUPS
1 acl create path=@BACKUPS
1 acl unlink path=@BACKUPS
1 acl mkdir path=@BACKUPS
1 acl rmdir path=@BACKUPS
1 acl mkfifo path=@BACKUPS
1 acl mksock path=@BACKUPS
1 acl truncate path=@BACKUPS
1 acl symlink path=@BACKUPS
1 acl mkblock path=@BACKUPS
1 acl mkchar path=@BACKUPS
1 acl link old_path=@BACKUPS
1 acl link new_path=@BACKUPS
1 acl rename old_path=@BACKUPS
1 acl rename new_path=@BACKUPS
1 acl chmod path=@BACKUPS
1 acl chown path=@BACKUPS
1 acl chdrp path=@BACKUPS
1 acl ioctl path=@BACKUPS
1 acl mount source=@BACKUPS
1 acl mount target=@BACKUPS

I think I covered all operations that can modify files, excluding all that read 
only.

2. I wonder why operations like touch file (acl create) report ENOENT instead 
of EPERM (which would be logical). ENOENT is confusing.

Best regards,

27.12.2012, 15:22, "[email protected]" <[email protected]>:
> Hello Tetsuo Handa,
>
> I think it may be useful for CaitSith to have also more generalized actions, 
> like readonly_access and writable_access.
>
> For example, if I want to make some subdirectory tree globally read-only (I 
> think that could be very common wish) now I need to add many similar acl 
> rules to deny all actions what can modify, add, rename, link, unlink, chmod, 
> truncate, append, mk*, chown, and chgrp files in it. That is like 12 rules 
> with the same path and rules, which is heavy duplication. It will be much 
> easier to understand and write single rule which includes all these actions 
> in good way. So, for example, I would write
>
> 1 acl writable_access path="/home/repo/\(\*\)/\*"
>   1 deny task.exe!="/usr/local/bin/repo-accessor"
>   1 allow
>
> Instead of 12 similar rules.
>
> Best regards,
>
> _______________________________________________
> tomoyo-users-en mailing list
> [email protected]
> http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en

_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en

Reply via email to