<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: How to create shared space on a Linux machine (for idiots)	</title>
	<atom:link href="https://doncho.net/2004/05/how-to-create-shared-space-on-a-linux-machine-for-idiots/feed/" rel="self" type="application/rss+xml" />
	<link>https://doncho.net/2004/05/how-to-create-shared-space-on-a-linux-machine-for-idiots/</link>
	<description>Късчета живот</description>
	<lastBuildDate>Mon, 17 May 2004 09:00:15 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>
		By: Peter Pentchev		</title>
		<link>https://doncho.net/2004/05/how-to-create-shared-space-on-a-linux-machine-for-idiots/comment-page-1/#comment-174</link>

		<dc:creator><![CDATA[Peter Pentchev]]></dc:creator>
		<pubDate>Mon, 17 May 2004 09:00:15 +0000</pubDate>
		<guid isPermaLink="false">http://doncho.net/?p=80#comment-174</guid>

					<description><![CDATA[Actually, Nikola&#039;s guess about the user needing to log off is completely correct.  When a process tries to access some filesystem object, the kernel determines whether to allow it or not based on the process&#039;s current effective user ID and group access list.  The group access list is modified (actually, set) by the setgroups(2) syscall in login(1) (or login(8), depending on your OS).  Thus, once you log in, your group membership is &quot;set in stone&quot; for all commands and processes executed from your login shell.  If you modify a user&#039;s group membership in /etc/passwd, /etc/group, etc, those changes will *not* affect the user&#039;s currently-logged-in sessions - this explains why things didn&#039;t work before the reboot :)]]></description>
			<content:encoded><![CDATA[<p>Actually, Nikola&#8217;s guess about the user needing to log off is completely correct.  When a process tries to access some filesystem object, the kernel determines whether to allow it or not based on the process&#8217;s current effective user ID and group access list.  The group access list is modified (actually, set) by the setgroups(2) syscall in login(1) (or login(8), depending on your OS).  Thus, once you log in, your group membership is &#8220;set in stone&#8221; for all commands and processes executed from your login shell.  If you modify a user&#8217;s group membership in /etc/passwd, /etc/group, etc, those changes will *not* affect the user&#8217;s currently-logged-in sessions &#8211; this explains why things didn&#8217;t work before the reboot 🙂</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
