nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Different users cannot copy/execute files possibly due to extended attributes

twashing

Hey guys, pardon me if I seem new at this. I'm just learning about the concept of extended attributes. I'm trying to get support on a critical issue we're having on one of our Teamsite installations here.

The situation is that the teamsite user cannot write to a directory where it has umask permissions (see fig. 1 and fig. 2). Besides a user's umask, there are 2 other mechanisms that ZFS (Solaris' file system) uses to control access to files - Extended Attributes and Access Control Lists. I think ACLs are not the issue because the ACE on the directory in question allows full access to everyong (see fig. 3). Now, I can't find tools for getting/setting extended attributes on our Solaris boxes. I tried 'fsattr', but that's not in my path. Is that the tool one should use? Is it in root's path?

Also, is there a kind of umask or default set for extended attributes each time a file gets created. Where do extended attributes reside on the file system?
Through the teamsite UI, I was able to i) set my WORKAREA Sharing to 'Group' and ii) set permission overrides for a given role. But for these changes to take effect, you may have to restart Teamsite (I'm not sure). We should be able to control default extended attributes through the UI. Thanks a lot for any help.

2008/04/07 10:27:17 DEBUG> generate_page_portfolio.cgi:66 main:: - Generate command: [/app/iw-home/bin/iwgen -t "/iwmnt/
default/main/portfolio/WORKAREA/twashing/templatedata/common/article/presentation/XML.tpl" -r "/iwmnt/default/main/portf
olio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02/testarticletim" "/default/ma
in/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/testarticletim.xml"], result [/default/mai
n/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/testarticletim.xml: could not create]
fig. 1 (executed by teamsite with error)

twashing@sptfdelj07:02> pwd
/default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02
twashing@sptfdelj07:02> /app/iw-home/bin/iwgen -t "/iwmnt/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/presentation/XML.tpl" -r "/iwmnt/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02/testarticletim" "/default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/testarticletim.xml"
twashing@sptfdelj07:02> ls -la
drwxrwxrwx 2 twashing amgdev 512 Apr 7 11:21 ./
drwxrwxr-x 8 twashing amgdev 512 Mar 31 14:02 ../
-rw-rw-r-- 1 twashing amgdev 2691 Mar 27 16:23 testarticledcr.xml
-rw-rw-r-- 1 twashing amgdev 2699 Mar 27 16:27 testarticledcrzzz.xml
-rw-rw-r-- 1 twashing amgdev 2608 Apr 7 11:21 testarticletim.xml
twashing@sptfdelj07:02>
fig. 2 (exact same command as in fig. 1, executed by twashing with no error)

twashing@sptfdelj07:~> getfacl /default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/
# file: /default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/
# owner: twashing
# group: amgdev
user::rwx
group::rwx #effective:rwx
mask:rwx
other:rwx
fig. 3 (ace provides full access to all people)

Tim Washington
Java Analyst; Portfolio.com; Conde Nast
twashing@condenast.com
212.286.2989

Find more posts tagged with

Comments

ISCBorisB

fsattr is not a shell command, see here. It's a namespace to associate arbitrary tree structure with the File + an interface to manipulate such structures.

Please note that TeamSite Extended Attributes do not use this mechanism. In TS Extended Attributes are scalar name/Value pairs,
used by the System and exposed to TS Developers as well. TS Metadata is the subset of TS Extended Attributes most often used,
see some discussion [post=111775]here[/post]. Metadata Capture (MDCT) TS structures allow you to develop Content Contributors GUI
to set Assets' Metadata. TS extended attributes are kept in the backing store and are not available for direct access.

From the CLT prospective iwextattr is the Command to use. You may want to try the following from the command prompt:
`iwgethome`/bin/iwextattr -h

Hth

twashing

Hi ICSBorisB, thanks for the feedback. I actually do use iwextattr to get/set attributes on files. I'm not quite sure how to list out the extended attributes for a file/directory though. My tries below don't work. But more importantly, the first command (in fig. 1) should work since the interwoven user has all umask permissions to operate on that directory. If I run that exact same command (fig. 2), it works fine. So I'm wondering what mechanism is preventing the interwoven user in fig. 1, if umask, ACL, and extAttr all allow the operation.

twashing@sptfdelj07:02> iwextattr -e //sptfdelj07/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02
NextEA failed, err = 2439
twashing@sptfdelj07:02> iwextattr -l //sptfdelj07/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02
NextEA failed, err = 2439
twashing@sptfdelj07:02>
twashing@sptfdelj07:02>
twashing@sptfdelj07:02> iwextattr //sptfdelj07/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02
NextEA failed, err = 2439

ISCBorisB

Your syntax is actually correct.

An error you see is one of the TS CLT Commands peculiarities (to put it mildly). Error 2439 with -l/e flags simply means that there are
no EAs set for this particular Asset. Try it with something that does have EAs, take for example any DCR or template-generated File.

...the first command (in fig. 1) should work since the interwoven user has all umask permissions...

How do you know? You use some custom CGI to call the command in question, how do you invoke this CGI? What is the CGI process effective UID?
Does it belong to "amgdev" Group? Does this account have 'w' permissin on the File? Further, it looks like you are modifying (trying to?) an existing
File, therefore 'umask' is not at all a factor.

twashing

The location "/default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/" is the directory into which we cannot generate the file. If I take a look at directory permissions and the interwoven user permissions, We can see that the interwoven user has rights to write to that directory:

twashing@sptfdelj07:bin> ls -ld /default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/
drwxrwxrwx 2 twashing mygoup 512 Apr 14 15:03 /default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/

twashing@sptfdelj07:~> groups iwuser
... mygroup ...

And just to know that we're looking at the correct user:
twashing@sptfdelj07:bin> ps -e -o user -o pid -o tty -o time -o comm | grep iwuser
...
iwuser 11330 ? 00:00 /app/iw-home/iw-webd/bin/iwwebd
iwuser 11331 ? 11:31 /app/iw-home/iw-webd/bin/iwwebd
...
root 11299 ? 01:44 /app/iw-home/iw-webd/bin/iwwebd

ISCBorisB

Effective UID of the process that executes "generate_page_portfolio.cgi" is almost certainly not 'iwuser'. So once again, what is it?
Can you add the following into CGI right before you execute iwgen? What does it show?

my $login = getlogin || getpwuid($<) || "UNKNOWN";
# print $login into some Log File.

twashing

Well I don't have either of those commands in my path so perhaps this is something for the AppAdmins to look into:

twashing@sptfdelj07:~> getlogin
-bash: getlogin: command not found
...
twashing@sptfdelj07:~>
twashing@sptfdelj07:~> getpwuid
-bash: getpwuid: command not found

ISCBorisB

Well I don't have either of those commands in my path so perhaps this is something for the AppAdmins to look into:

twashing@sptfdelj07:~> getlogin
-bash: getlogin: command not found
...
twashing@sptfdelj07:~>
twashing@sptfdelj07:~> getpwuid
-bash: getpwuid: command not found

Sorry man, I give up.

Neither getlogin() nor getpwuid() are Unix Shell commands. Your Administrators will not have them in their Path either.
Both are Perl Functions, by asking you to place code within your CGI script I've tried to help you to find out how CGI
execution gets impersonated (who in fact runs it)

twashing

Let's keep hope alive!! I'm trying it out right now Smiley Wink

twashing

Ok, I tried it out and we are indeed running as the correct user. It's a very strange problem.

2008/04/14 17:58:09 DEBUG> generate_page_portfolio.cgi:68 main:: - Logged-in user: [iwuser]

... same as before
2008/04/14 17:58:09 DEBUG> generate_page_portfolio.cgi:69 main:: - Generate command: [/app/iw-home/bin/iwgen -t
"/iwmnt/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/presentation/XML.tpl" -r "/iwmnt/
default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02/t
estarticletim" "/default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/testar
ticletim.xml"], result [/default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/0
2/testarticletim.xml: could not create]

nipper

You should make certain that this user has access to all the directories from the Workarea root down to the folder you are trying to change, you may want to reading all the folders down. Also, verify that this workarea is set to sharing to a group that this user is a member.

twashing

Thanks for responding. Yes, the group sharing is something we tried already. And the directory in question has all the read access necessary for the interwoven user. I'll double -check all of these settings just to be sure.

ISCBorisB

Thanks for responding. Yes, the group sharing is something we tried already. And the directory in question has all the read access necessary for the interwoven user. I'll double -check all of these settings just to be sure.

Just to close this line of the investigation, can you print uid/euid separately?

my $uid = getpwuid($<);
my $euid = getpwuid($>);
# print $uid and $euid to the Log

Adam Stoller

Hi ICSBorisB, thanks for the feedback. I actually do use iwextattr to get/set attributes on files. I'm not quite sure how to list out the extended attributes for a file/directory though. My tries below don't work. But more importantly, the first command (in fig. 1) should work since the interwoven user has all umask permissions to operate on that directory. If I run that exact same command (fig. 2), it works fine. So I'm wondering what mechanism is preventing the interwoven user in fig. 1, if umask, ACL, and extAttr all allow the operation.

twashing@sptfdelj07:02> iwextattr -e //sptfdelj07/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02
NextEA failed, err = 2439
twashing@sptfdelj07:02> iwextattr -l //sptfdelj07/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02
NextEA failed, err = 2439
twashing@sptfdelj07:02>
twashing@sptfdelj07:02>
twashing@sptfdelj07:02> iwextattr //sptfdelj07/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02
NextEA failed, err = 2439

Adam Stoller

Thanks for responding. Yes, the group sharing is something we tried already. And the directory in question has all the read access necessary for the interwoven user. I'll double -check all of these settings just to be sure.

When you are within the workarea (at least within CCPro) you should have a Permissions button/link towards the upper-right-hand-corner of the screen - you might try utilizing that on the files and/or directories leading up to, and including, where you are trying to create the files.

smwangi

The most common cause for this error is insufficient permisions for a directory or folder high up the path. Try creating the file at the Workarea level and keep working your way down until you hit the error.

twashing

Just to close this line of the investigation, can you print uid/euid separately?

my $uid = getpwuid($<);
my $euid = getpwuid($>);
# print $uid and $euid to the Log

I tried this out and the users look good:

2008/04/15 09:49:24 DEBUG> generate_page_portfolio.cgi:70 main:: - UID: [iwui]
2008/04/15 09:49:24 DEBUG> generate_page_portfolio.cgi:71 main:: - EUID: [iwui]
2008/04/15 09:49:24 DEBUG> generate_page_portfolio.cgi:72 main:: - Generate command: [/app/iw-home/bin/iwgen -t
"/iwmnt/default/main/portfolio/WORKAREA/twashing/templatedata/common/article/presentation/XML.tpl" -r "/iwmnt/
default/main/portfolio/WORKAREA/twashing/templatedata/common/article/data/business-travel/features/2008/02/02/t
estarticletim" "/default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/02/testar
ticletim.xml"], result [/default/main/portfolio/WORKAREA/twashing/contentxml/business-travel/features/2008/02/0
2/testarticletim.xml: could not create]

twashing

When you are within the workarea (at least within CCPro) you should have a Permissions button/link towards the upper-right-hand-corner of the screen - you might try utilizing that on the files and/or directories leading up to, and including, where you are trying to create the files.

Yes. This was it. In one of the ancestor directories, the permissions was read-only for "others". Coolio.

twashing

The most common cause for this error is insufficient permisions for a directory or folder high up the path. Try creating the file at the Workarea level and keep working your way down until you hit the error.

Yes, you are correct. In one of the ancestor directories, the permissions was read-only for "others". Thanks for the input.

twashing

ISCBorisB, thanks a lot for your help. This was show stopper for us.

twashing

You should make certain that this user has access to all the directories from the Workarea root down to the folder you are trying to change, you may want to reading all the folders down. Also, verify that this workarea is set to sharing to a group that this user is a member.

Thanks for the tip. This turned out to be correct.