samba - Feb 2021 - Is “obey pam restrictions” still supposed to work in Samba 4?

On Wed, 2021-02-10 at 22:03 +0100, Chentao Credungtao via samba
wrote:
> Hi,
> 
> The up-to-date Samba doc says 
> (https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html) :
> 
> "When Samba 3.0 is configured to enable PAM support (i.e. --with-
> pam), 
> this parameter will control whether or not Samba should obey PAM's 
> account and session management directives."
> 
> Is this still supposed to work with Samba 4 ? I had some strange
> result, 
> it seems PAM's restrictions are enforced once, but then not anymore.
It should work, but not for this purpose.  The session managment hook
helps run things like pam_mkhomedir and the account hooks try to ensure
Samba stays in line with restrictions on (eg) ssh.
> 
> I tried to set up a file-size limitation on a Samba share. I'm not 
> talking about quotas, I'm talking about preventing users from
> storing 
> files that are bigger than 100MB, for example. I used 
> /etc/security/limits.conf for this.
> 
> It almost works. Well, it works the first time a user tries to create
> a 
> file, and then not anymore.
> 
> 
> Here's what I did :
> 
>      - First I defined a hard filesize limit of 100MB for user
> johndoe 
> in /etc/security/limits.conf :    "johndoe    hard fsize   
102400"
> 
>      - Then I added "session required pam_limits.so" to 
> /etc/pam.d/samba, in order to tell PAM to enforce the limitations
> 
>      - And finally, I added "obey pam restrictions = yes" to 
> /etc/samba/smb.conf
This actually causes quite a problem.  The last session setup to be
handled via this smbd process sticks, and it sets limits that interfere
with Samba's normal operation, not just user files.  It can limit the
number of files Samba can open for example.
> At first it seemed promising, when user johndoe tries to copy a file
> > 
> 100MB, a Windows 10 client throws the following error : An
> unexpected 
> error is keeping you from copying the file...An unexpected network
> error 
> occured
That would be Samba getting SIGXFSZ per man setrlimit:

      RLIMIT_FSIZE
              This  is the maximum size in bytes of files that the process may
create.  Attempts to extend a file beyond this limit result in delivery of a
SIGXFSZ
              signal.  By default, this signal terminates a process, but a
process can catch this signal instead, in which case the  relevant  system  call
(e.g.,
              write(2), truncate(2)) fails with the error EFBIG.
> So far, so good ! That's what I wanted, prevent the user to store a
> file 
>  > 100MB
> 
> But if I click on "Try again", the file is copied anyway.
I'm not sure exactly why this happens, but it might be due to another
SMB session being created after and changing the limits again.  I'm not
sure, but we do know this behaviour (limits being read via PAM) is not
desired and need to remove it at some point. 
> And if I then try to copy more files > 100MB, no more error message
> is 
> thrown, and the copies proceed.
> 
> If user johndoe logs out and back in, same result : the first
> attempt 
> throws an error, the following attempts succeed.
> 
> So, it seems the restriction I set in /etc/security/limits.conf is
> only 
> enforced at the first attempt, and is no more enforced afterwards.
> 
> Any idea why ? Or any idea how I could achieve my goal (prevent a
> user 
> to copy a file > 100MB) ?
Not via this method.  I suggest overall file quotas, but that wouldn't
stop individual files growing.

Sorry!

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT - Expert Open Source
Solutions
https://catalyst.net.nz/services/samba

>Not via this method.  I suggest overall file quotas, but that wouldn't
stop individual files growing.
>Sorry!
So, to sum things up, limiting the size of individual files cannot be 
achieved, only overall quotas can be implemented.

If I understand you right, the files on the samba server aren't created 
by the end user (e.g. johndoe) , but by some kind of samba hook, and 
that's why the restrictions defined in limits.conf aren't enforced (or 
are only enforced at the first attempt, according to my tests).

Many thanks for your support and your very clear answer !

It's always useful to know what can and what cannot be done. I had some 
doubts because someone gave this limits.conf solution, but I guess he 
probably didn't test it himself 
(https://unix.stackexchange.com/questions/105534/restrict-samba-user-for-upload-files-based-on-file-size)

Again, many thanks


On 10/02/2021 22:20, Andrew Bartlett via samba wrote:
> On Wed, 2021-02-10 at 22:03 +0100, Chentao Credungtao via samba wrote:
>> Hi,
>>
>> The up-to-date Samba doc says
>> (https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html) :
>>
>> "When Samba 3.0 is configured to enable PAM support (i.e. --with-
>> pam),
>> this parameter will control whether or not Samba should obey PAM's
>> account and session management directives."
>>
>> Is this still supposed to work with Samba 4 ? I had some strange
>> result,
>> it seems PAM's restrictions are enforced once, but then not
anymore.
> It should work, but not for this purpose.  The session managment hook
> helps run things like pam_mkhomedir and the account hooks try to ensure
> Samba stays in line with restrictions on (eg) ssh.
>
>> I tried to set up a file-size limitation on a Samba share. I'm not
>> talking about quotas, I'm talking about preventing users from
>> storing
>> files that are bigger than 100MB, for example. I used
>> /etc/security/limits.conf for this.
>>
>> It almost works. Well, it works the first time a user tries to create
>> a
>> file, and then not anymore.
>>
>>
>> Here's what I did :
>>
>>       - First I defined a hard filesize limit of 100MB for user
>> johndoe
>> in /etc/security/limits.conf :    "johndoe    hard fsize   
102400"
>>
>>       - Then I added "session required pam_limits.so" to
>> /etc/pam.d/samba, in order to tell PAM to enforce the limitations
>>
>>       - And finally, I added "obey pam restrictions = yes" to
>> /etc/samba/smb.conf
> This actually causes quite a problem.  The last session setup to be
> handled via this smbd process sticks, and it sets limits that interfere
> with Samba's normal operation, not just user files.  It can limit the
> number of files Samba can open for example.
>
>> At first it seemed promising, when user johndoe tries to copy a file
>> 100MB, a Windows 10 client throws the following error : An
>> unexpected
>> error is keeping you from copying the file...An unexpected network
>> error
>> occured
> That would be Samba getting SIGXFSZ per man setrlimit:
>
>        RLIMIT_FSIZE
>                This  is the maximum size in bytes of files that the process
may create.  Attempts to extend a file beyond this limit result in delivery of a
SIGXFSZ
>                signal.  By default, this signal terminates a process, but a
process can catch this signal instead, in which case the  relevant  system  call
(e.g.,
>                write(2), truncate(2)) fails with the error EFBIG.
>
>> So far, so good ! That's what I wanted, prevent the user to store a
>> file
>>   > 100MB
>>
>> But if I click on "Try again", the file is copied anyway.
> I'm not sure exactly why this happens, but it might be due to another
> SMB session being created after and changing the limits again.  I'm not
> sure, but we do know this behaviour (limits being read via PAM) is not
> desired and need to remove it at some point.
>
>> And if I then try to copy more files > 100MB, no more error message
>> is
>> thrown, and the copies proceed.
>>
>> If user johndoe logs out and back in, same result : the first
>> attempt
>> throws an error, the following attempts succeed.
>>
>> So, it seems the restriction I set in /etc/security/limits.conf is
>> only
>> enforced at the first attempt, and is no more enforced afterwards.
>>
>> Any idea why ? Or any idea how I could achieve my goal (prevent a
>> user
>> to copy a file > 100MB) ?
> Not via this method.  I suggest overall file quotas, but that wouldn't
> stop individual files growing.
>
> Sorry!
>
> Andrew Bartlett
>