[pulseaudio-discuss] Failed to create secure directory with ACL

[Alexander E. Patrakov]

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