Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Sshfs and umask

56 views
Skip to first unread message

Paul van der Vlis

unread,
Oct 18, 2017, 6:10:06 AM10/18/17
to
Hello,

I try to force the umask of an sshfs on the server side.

I've tried /etc/ssh/sshd_config with for example:
Subsystem sftp /usr/lib/openssh/sftp-server -u 0002
or:
ForceCommand internal-sftp -u 0002
But this does not change the umask.

And adding "session optional pam_umask.so umask=0002" to
/etc/pam.d/sshd/ does change the umask for ssh, but not for sshfs.

Does somebody understand where it goed wrong?

With regards,
Paul van der Vlis


--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/







--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Sven Hartge

unread,
Oct 18, 2017, 11:40:05 AM10/18/17
to
Paul van der Vlis <pa...@vandervlis.nl> wrote:

> I try to force the umask of an sshfs on the server side.

> I've tried /etc/ssh/sshd_config with for example:
> Subsystem sftp /usr/lib/openssh/sftp-server -u 0002
> or:
> ForceCommand internal-sftp -u 0002
> But this does not change the umask.

> And adding "session optional pam_umask.so umask=0002" to
> /etc/pam.d/sshd/ does change the umask for ssh, but not for sshfs.

> Does somebody understand where it goed wrong?

The umask can only enforce stricter permissions, i.e. the client wants
to set 0777 but the file gets set to 0775 in your case.

But it can't set wider permissions. If the client sets the permissions
to 0700 then no umask in the world will get you to 0775.

Dirty hack: use something like incron to trigger a script via inotify to
change the permssions.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Paul van der Vlis

unread,
Oct 18, 2017, 6:00:06 PM10/18/17
to
Op 18-10-17 om 17:31 schreef Sven Hartge:
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>> I try to force the umask of an sshfs on the server side.
>
>> I've tried /etc/ssh/sshd_config with for example:
>> Subsystem sftp /usr/lib/openssh/sftp-server -u 0002
>> or:
>> ForceCommand internal-sftp -u 0002
>> But this does not change the umask.
>
>> And adding "session optional pam_umask.so umask=0002" to
>> /etc/pam.d/sshd/ does change the umask for ssh, but not for sshfs.
>
>> Does somebody understand where it goed wrong?
>
> The umask can only enforce stricter permissions, i.e. the client wants
> to set 0777 but the file gets set to 0775 in your case.
>
> But it can't set wider permissions. If the client sets the permissions
> to 0700 then no umask in the world will get you to 0775.

Thanks for the information, I have tested it and it's correct. I can set
a stricter permission.

> Dirty hack: use something like incron to trigger a script via inotify to
> change the permssions.

That's possible, I can think about it.

> Grüße,
> Sven.

Groeten, Paul

Sven Hartge

unread,
Oct 18, 2017, 6:10:04 PM10/18/17
to
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> Op 18-10-17 om 17:31 schreef Sven Hartge:
>> Paul van der Vlis <pa...@vandervlis.nl> wrote:

>>> And adding "session optional pam_umask.so umask=0002" to
>>> /etc/pam.d/sshd/ does change the umask for ssh, but not for sshfs.
>>
>>> Does somebody understand where it goed wrong?
>>
>> The umask can only enforce stricter permissions, i.e. the client wants
>> to set 0777 but the file gets set to 0775 in your case.
>>
>> But it can't set wider permissions. If the client sets the permissions
>> to 0700 then no umask in the world will get you to 0775.

> Thanks for the information, I have tested it and it's correct. I can
> set a stricter permission.

>> Dirty hack: use something like incron to trigger a script via inotify
>> to change the permssions.

> That's possible, I can think about it.

You also could try Posix-ACLs.

(The last time, I tried to use them for a similar use case, I lost
nearly all my hair, but YMMV.)

S°
0 new messages