20.04.2014 16:04, Prunk Dump wrote:
2014-04-17 14:09 GMT+02:00 Alexander E. Patrakov <[email protected]>:
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 <[email protected]>:
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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
