20.04.2014 16:04, Prunk Dump wrote: > 2014-04-17 14:09 GMT+02:00 Alexander E. Patrakov <patrakov at gmail.com>: >> Well, the problem here is that the CIFS server gives extra unwanted access >> rights to the directory. So PulseAudio rightfully complains. However, in >> some cases (e.g. on CIFS and other non-native filesystems), this error is >> not actionable. > > Yes, same result with mkdir --mode=0700. But I think there are not > unwanted access rights. When Acls are enabled the standard POSIX bits > have not the same sense. So you can't use ls -l or lstat() to get > file's access rights. The "+" on ls -l show that "getfacl" need to be > used. > >>>> $ls -al /home/teachers/pellegrb >>>> >>>> drwxrwx---+ 2 pellegrb teachers 0 avril 7 14:02 .pulse Yes, "+" means that there are ACLs. However, the standard POSIX permissions are translated to so-called "base" ACL entries (those with the empty second column). > As I understand every seems ok in the ACL sense. Not sure. > When I create the > directory the default permissions are inherited : > > $mkdir /home/teachers/pellegrb/.pulse > $ls -al /home/teachers/pellegrb > > drwxrwx---+ 2 pellegrb teachers 0 avril 7 14:02 .pulse > > $getfacl /home/teachers/pellegrb/.pulse > # file: home/teachers/pellegrb/.pulse > # owner: pellegrb > # group: teachers > user::rwx > user:3000038:r-x This looks wrong. Namely, why does the CIFS server give "r-x" access to the nameless user with the uid equal to the gid of the "teachers" group? > group::r-x > group:teachers:r-x > group:3000137:rwx Same here. Why does the CIFS server give "rwx" rights to the nameless group with the gid equal to your UID? Maybe this is somehow related to the fact that, in Windows, there is a shared space of IDs for users and groups? > mask::rwx That is, nothing is masked from non-base ACL entries. > other::r-x > default:user::rwx > default:user:pellegrb:rwx > default:group::r-x > default:group:teachers:r-x > default:mask::rwx > default:other::r-x Default ACL entries are copied to the files in the subdirectory. > And when I chown the file (useless) and chmod it, the "group" and > "other" right access are changed : > > $chown 3000137:3000038 /home/teachers/pellegrb/.pulse > $chmod 0700 /home/teachers/pellegrb/.pulse > $getfacl /home/teachers/pellegrb/.pulse > # file: home/teachers/pellegrb/.pulse > # owner: pellegrb > # group: teachers > user::rwx > user:3000038:r-x > group::--- > group:teachers:r-x > group:3000137:rwx > mask::rwx > other::--- > default:user::rwx > default:user:pellegrb:rwx > default:group::r-x > default:group:teachers:r-x > default:mask::rwx > default:other::r-x Well, for a complete understanding I need the following sequence of commands: rm -rf dummy mkdir -m 0700 dummy ls -ld dummy getfacl dummy chown 3000137:3000038 dummy ls -ld dummy getfacl dummy chmod 0700 dummy ls -ld dummy getfacl dummy > > This behavior is the same with EXT4 ACLs, it seems not a CIFS problem. > But PulseAudio doen't check ACLs on home folders. > > 2014-04-17 14:09 GMT+02:00 Alexander E. Patrakov <patrakov at gmail.com>: >> Instead, I suggest to ignore fchown() failures that are not even supposed to >> be actionable and are not security-relevant, with a warning. IMHO a good >> heuristic to decide whether to propagate fchown() failures would be uid != >> -1, or, equivalently, a test for system mode. > > Excuse me Alexander, I'am french and I don't understand your > suggestion. Your suggestion is for me or for a code source > modification ? I don't understand what is a "actionable error" and how > can I ignore the fchown() failures. This is a suggestion for source code modification. "Actionable error" means an error that one can completely remove (as opposed to "live with it" or to "ignore it" or to "ask someone else to remove it"). An example would be "access denied" to your own file - just chmod it and see the error go away. A counter-example would be "access denied" to a file that belongs to someone else - in this case there is nothing you can do to fix it. > In my case pulse audio won't start ! It is not only a warning. But in > reality the .pulse folder is secured, no other user can access its > contents. Yes, the proposal would be to modify PulseAudio to ignore this error in some cases. I will prepare a patch later today. -- Alexander E. Patrakov
