Regarding ACL permission
 

Hi Folks,

I work for an organisation where we need to transform ClearCase to Interity with the ACL security.

When I say Integrity, it has two ways to support, the check-in and check-out of files happens on PTC Integrity tool with securities on Unix as well as on Windows based systems.

I would like to know everything about the ACL security and its different ways to set the permissions etc.

I have been using linux/Unix from the past 5 years. Right now, I am on Unix Solaris platform and a perl script developer.

Please help/suggest to improve the knowledge about the ACL security and any suggestions to leverage the existing perl/shell script would be a great support.

The basic question in my mind ?

when I set the ACL permissions to certain files on Unix/Linux and transfer these files to Windows, will these file permissions remains same ? to make these file permissions consistent, what is that required to capture and modify ? W.R.T ACL security ?

Please post your thread in only one forum. Posting a single thread in the most relevant forum will make it easier for members to help you and will keep the discussion in one place.

I would suggest an internet search of ACLs and SE-Linux as the best way to improve your knowledge of ACL implementation and use. A simple introduction with some related links may be found here.

Hi astrogeek,

Your suggestion to internet search for ACL`s is of useless.

internet search is what everyone will do, there is a reason for seeking suggestions here in the forum to get the most appropriate direction from the experts or to connect with the familiar users.

In answer to this...

Only you can "improve" your knowledge on any subject. If you want to "know everything" about ACL security, then you are going to have to search out information on the subject, read and understand it. An internet search is indeed, the best place to start, as stated in the Site FAQ, What makes a good issue description?:

Although members are always happy to help you learn, the purpose of LQ is not to put you in touch with tutors and experts, or to serve as a help desk. It is to allow you to receive help for specific problems or things that you are not able to understand on your own.

Please review the Site FAQ for guidance in acceptable forum participation and asking your questions.

I do not know the definitive answer to the second part of your question, but I know of no general mechanism that would allow ACLs to follow a file transfer from one system to another, especially from a Linux machine to a Windows machine.

Perhaps someone with that knowledge will join the discussion. In the mean time, you may want to use the LQ Search feature available from any page, or, again, use your internet search engine of choice.

Agreed !..will soon come up with understanding of ACL`s security and with more questions here.

Hey, let's try to get the OP some answers here, shall we? :tisk:

There is, unfortunately, no single standard format for ACLs. Windows SMB did it one way, Windows CIFS another, NFS(v3)(v4) did it another, Linux another, POSIX another, and so on. :rolleyes:

The format of the rules, complexity of the rules, identification of the affected party, and set of restrictions that you can impose are not the same. Therefore, various kinds of ACL translation take place. RFC standards have been written describing all of them, and all of them are technical compromises.

For example, Unix users are identified by a numeric UID, whereas Windows users are identified internally by a string-token SID. It will be very important for your company to be able to sensibly and efficiently manage this cross-platform arrangement while providing the correct security limits no matter from which side the request originates.

Various articles on the subject include these:

• NVS V4 ACL Translation (IBM)
• Using Permissions on a Lenovo® Storage Device (PDF)
• Introduction to NFSv4 ACLs (Linux-NFS.org)

... and the list goes on.

From the last article:

Did you try putting "clearcase to mks integrity migration" into Google??? Some of the very first hits:
https://www.ptcusercommunity.com/thread/51025
https://www.ptcusercommunity.com/thread/126519

...are from their forums, where folks have done this before, and there are many others as well. And as far as I'm aware, Integrity is a commercial, pay-for product; when you purchase it, you are entitled to support. They would be easily able to answer your questions.
http://www.ptc.com/application-lifec...ment/integrity
As astrogeek said, you can easily look ACL information up and educate yourself. Please don't ask us to look things up for you..we have no idea what you already know, and ACL's are a complex subject. This is similar to other threads you've posted in the many years you've been here:
http://www.linuxquestions.org/questi...am-4175577287/
http://www.linuxquestions.org/questi...-stuff-941254/
http://www.linuxquestions.org/questi...nswers-941843/

...and you re-opened three old threads to post questions too. Please read the LQ Rules and "Question Guidelines".
Since you don't post the 'existing perl/shell script' you're talking about, how would we know if you can leverage it or not? You are saying you have five years experience as an administrator, and in the past, said you were working on your doctorate. As a doctoral candidate, you should be well familiar with how to ask questions and perform research.
Since permissions on Windows and Linux are not the same, the better question is: will the file permissions be equivalent to what they were on the source platform, and provide the same level of security? You will have to work closely with your Windows administrators to get this nailed down into something that fits your organization and requirements.

Personally, this is not something I'd script/program for. I would migrate one project over to a test environment in a lab, and make sure that I totally understood what was going on. I'd also take the opportunity to re-organize things, because if this is a larger environment, there are probably things that are shoved in places they don't need to be, because it was expedient at the TIME to do so. Talk with your developers, and see if they want to/need to have things shuffled around while you're in the midst of a migration. Get old users deleted, make sure the current ones are up to date, etc. I'd migrate one project over at a time, manually, to the test environment, and make absolutely *CERTAIN* that things were right. Since this goes on behind the scenes and doesn't affect production, you can take your time. Once you've got things squared away, THEN you can run an automated dump of the current system to the new, and make the new system your production unit, taking the old one offline, but keeping it handy.

Indeed ... most of all, you need to be thoroughly certain that you do, indeed, obtain the results that your project requires: users have exactly the access that they require, to exactly the resources they require, from whatever machine and type-of-machine they are using. You must also be certain that the administrative management controls work correctly and sensibly in all cases.

As TB0ne notes, it's not a simple matter of "seeing that 'it works.'" Your task will be to make apples and oranges work together as seamlessly as you can manage.

If your OS supports ACLs, its man page for chmod etc. should contain plenty of information.

But... there's more to it than this. This is a cross-platform situation, thus the "intent" of each ACL, placed "here" (wherever "here" may be) must be acceptably carried-out also "over there" (ditto). This means some kind of acceptable transformation between apples and oranges, "which varies from fruit to fruit." :)

It's well-documented – even standardized – but nevertheless a necessary compromise, of which users in the OP's situation must make themselves aware.

If I need to test the ACLs with in a vertualbox and test it similar to my OP. How do I test this ? just confused of all these ACLs.
make permissions in ubuntu and carry the files over to windows etc... looking for a personnel test setup.

You were told how, and given a migration plan and pointed to documentation on doing what you're after. Not sure how much more you'd like.

AGAIN...set up a test environment on whatever you want. Migrate one piece over, and test it. Repeat that for everything, until you figure it out....that is the job.

To conduct proper research you will probably need at least two VMs, one for each type of system that you are dealing with.

Then, you need to :study: search the Internet for discussions of your particular scenario, and carefully consider the type of ACL rules you will need to have on both sides. You need to determine if ACLs issued on one side are acceptably also created on the other. You'll need to test attempts (on both sides) to get access that you want to occur, as well as attempts to gain what you want to prevent.

It's going to be a meticulous research project. Not particularly fun, but very important that it be done well.

●MAC (mandatory access control: e.g. SElinux), DAC (discretionary access control: e.g. Linux rwx permissions/user and groups), ACL (access control lists: this is a broadterm, but with a specific meaning, which is obvious. Its broad cus DAC and MAC are types of an ACL, there are more such as RSBAC (rule set based authentication control) etc..

●MAC will stop XSS (but malware is still in the system, it just cant do anything) as these MAC systems will not let the browser, or any other process to rwx any file not allowed by the policy. EXCEPT files owned by the brower, or whatever thats compromised, which is why you make sure their owned by a user without any priviledges... But MAC sort of acts like a sandbox anyway, so even malware with root will be contained to the infected program and its policies...

●MACs can even stop zero days, but there are exceptions due to the way the linux kernel is designed. For example if you can get a code path to some low level kernel function and if you are good enough to right a proper exploit, you can essentially overide a MAC...

●MAC options: SElinux, AppArmor, GRsecurity, SMACK, TOMOYO. RSBAC (kinda like AppArmor in terms on simplicity, I think)

●RBAC is designed for separation of duties by letting admins select the roles for users that need to perform a specific task.

●SElinux enforces MAC ACL (mandatory access control) and this works by dissallowing IPC (inter process communication) in systems with standard process isolation, as even with such systems that by default use process isolation IPC is still allowed via shared memory, internet sockets, and local sockets. (I think it works this way)
* SElinux is a flexible MAC ACL framework that sets defined partitions between data, applications, and processes. While DAC ACL does something similar, it's policies can be changed at the discretion of the user (with DAC there is more attack surface for malware/rogue processes masquerading as your UID/GID)
* SElinux is implemented as an LSM (I think its in almost every pre-compiled kernel)
* SElinux provides features such as black/white listing ioctls, or restricting loading of kernel modules, etc...

●AppArmor is quick solution to SElinux

As per my OP, I tried to understand few things regarding the ACLs. As I have to concentrate on Unix Solaris and Linux OS, my focus would be on Unix Solaris.
As per my understanding there are two types of ACLs NFSv4 and POSIX ACLs and these ACLs vary from File system to File system(FS to FS) and these ACLs are similar but not exactly same, we need to be careful while implimenting the permissions.
and
there fore, mine is a NFSv4 and ZFS File Sytem.
As I could see:
So, the latest File System is ZFS ,we also have the legacy old UFS(Universal Fyle System) and different tempfs mounted on the servers.
Now, we have two types of ACLs again if we are going with the chmod way of setting it:

Trivial and non trivial:
Trivial is a very common way of setting the r,w,x permissions
Non-Trivial is not a traditional way, it has lot of other additions to inherit ect.

for more details: